Why Use a .dmg?
Aside for Mac Devs: Yes, I decided to go with a .zip archive for this release, instead of a tried and true .dmg. Here’s why: 1) It “safe opens” exactly the same as a .dmg would, extracting the application and thoughtfully trashing the .zip. 2) If people have “safe open” turned off, there’s no chance of classic “running it off the .dmg” user confusion — also known as “the question mark in the dock experience”, a great band name — as the user just double clicks the .zip to get the app in a pure form. 3) They’re easier to make, and a little bit smaller too. And not a single e-mail (yet) about the change? That’s-a hot-a zip!
Disk images are the preferred container for software products on Mac OS X. They allow you to group a set of files in a compact format that is easily handled by users. These enclosures are easily transported across a network because they appear as a single file. To access the contents of a disk image, a user double-clicks it in the Finder, which opens a standard Finder window showing the disk image’s contents. Compressed disk images allow you to use delivery vehicles—space-limited optical media or bandwidth-strapped networks—more efficiently.
The best container for delivering a product through the Internet is an Internet-enabled disk image. These containers are automatically opened and disposed of.
Except that is exactly someone’s experience when they download a .zip. Safari extracts it, then throws away the old copy. Unsurprisingly, the Finder opens a standard Finder window, as it always does. So what exactly is preferable about a .dmg? Nothing compelling that I am aware of.
Disk images have always seemed like an overly complex way to send a bundle of files to someone. I don’t like having to manually unmount them when I’m through with them.
And Apply says:
ZIP files: If your product can be used in operating systems other than Mac OS X, you may consider using a ZIP archive as the product’s container. To create a ZIP product container in the Finder, select the product directory in a Finder window and use the Create Archive command. You may also use the zip(1) command-line tool.
NOTE: the zip command-line tool is broken! (as of 10.4.9) Instead use
ditto -ckX --rsrc SOURCE_PATH DEST_PATH.zip.
All in all, .zip files look pretty nice to me.
But my final decision is to stick with a .dmg, for now. Since IMLocation is in beta, I include a ReadMe and an uninstaller inside the .dmg. I feel they are necessary for now, just in case. While I’m not convinced that a .dmg is the best way to send a group of files to someone, it is “standard practice”.
However, my goal is for the final version to not need a ReadMe and uninstaller prominently distributed with the main program. When I finally feel confident enough to distribute IMLocation as a single application-bundle, I plan to distribute it as a zip-file.
Conclusion: If you only have your-application bundle, and no other files, inside your .dmg then a .zip is better, otherwise stick with a .dmg … for now. There’s really nothing good about a .dmg, except it’s the “the way it’s always been done”. Once there’s a critical mass of “switchers” to another format there’s really no reason to stick with it. (EDITED TO ADD 2007-10-06 the more I think about it, the more I dislike the .dmg …)
EDITED TO ADD: Perhaps the most damming bit of evidence against the .dmg is that Apple distributes sample code both in both .dmg and .zip format. If the .dmg was so great you’d think it’d be all they’d use. Usually the .zip files are smaller..
EDITED TO ADD: Another black-mark against disk images is that you can’t cmd-click on an open one, and get the path back to the actual file — instead you get the path back to the virtual drive.
EDITED TO ADD: Making sure your program runs off of a .dmg takes work