Mac OS X Best Practices: Installers

by Jon Davis 9. June 2008 03:37

One of the things I really like about Mac OS X versus what I've seen in Windows et al is the way third party software gets installed. I've always heard people whine and complain about how applications for Windows should never use the Registry, should never touch the system directories, etc. In my mind, I saw such software practices as a necessary evil, and things are far worse in the Linux world, where the directories and file paths are far less predictable. I had thought these complaints were coming from Linux folks, but apparently not, they're coming mostly from Mac folks, I bet, because the Mac world has proven this stuff out.

Most apps are installed by copying the application directly into the Applications folder. The End.

Well, not quite, but that's pretty much it as far as the user is concerned. From the developer's / distributor's perspective, there are a few things to note.

  1. An application may appear as an individual file that has lots of resources embedded in it (I was a big tinkerer of ResEdit back in the day), but this is a facade in the OS X world. Applications are actually directories with a .app extension, and Finder (the Windows Explorer equivalent) treats these directories like files when browsing them, in that the folder has the application's icon, and double-clicking the icon opens the appropriately mapped executable file inside. (This behavior and other metadata is maintained with a file inside that has a .plist file extension. It's kind of like an app.config file in the Visual Studio .NET world, but it's not the same format at all.) "Power users" (or any user who's Mac savvy, or newbies like me who have experienced friends to show them this stuff) can access the contents of the folder by right-clicking (or Control + Left-clicking) the icon and choosing "Show Package Contents".
    I'm not sure yet what all goes on in here but I wouldn't be surprised if global application settings (like Windows' .ini files) can be modified here. Meanwhile, user preferences are managed in the user's home directory.
  2. Somewhat similar (IMO) to the custom folder display features in Windows' Active Desktop--which in Windows is partially incomplete on the directory/file shell level, was deprecated, and is rarely used because it was too powerful and too prone to abuse and malicious hacks, or maybe just too easy to be confusing and inconsistent in deployments--the Finder allows directories to be customized in layout and style so that when you open a CD-ROM (or disc image) and view its contents, it might appear elegantly like a running program that displays instructions on how to install (drag and drop to Applications), but really it's just a Finder view of the directory contents, with a custom background image and custom positioning of folders and files.
  3. Whereas Windows users must download Spyware-ridden Daemon Tools (even recommended by Microsoft) to mount .iso's to a drive letter, Mac OS X allows you to mount disc images (.dmg's) by double-clicking them. There is no drive letter, they just show up on the desktop and open automatically in the Finder (no annoying "what do you want to do with this?" dialogue, either).
  4. There is usually an alias to the /Applications directory right in the disk image's root folder, so basically when the customized layout displays text that says "drag and drop this icon to the Application folder", it is actually the distributed application's icon on the left, the Applications' folder alias on the right, and big, bold right arrow in the middle. (We all know what arrows mean, it's like a universal language.)
  5. Sometimes when an application gets dragged and dropped into the Applications directory, a quick script might execute. (Or, this is what a friend has told me, I'm still discovering all this.) I imagine that this allows for the initial creation of application environment settings. I'm not sure what the security or runtime constraints are on this, though. And I think--but am not certain--that this would be done in either AppleScript or Javascript.
  6. Sometimes an application needs to be installed, as in, integrated into the system. Services and developer tools are very frequently in this boat; application frameworks belong in several different directories, for example. For these situations, OS X uses a "package" or .pkg file, which is very similar to a Windows .msi file. Opening a .pkg file works much the same way as opening an .msi file, except a) I don't think it auto-detects prior installations and offers to uninstall or repair (??), and b) most of the .pkg installers that give installation path options seem to only offer hard drive selection, not folder selection. This kind of dumbs things down a bit but might be for the greater good of average users.

Here's an important documentation page I just stumbled across, and the motivation for posting this blog entry:

http://developer.apple.com/tools/installerpolicy.html

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Software Development | Mac OS X


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  September 2020  >>
MoTuWeThFrSaSu
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar