Downloading Applications

Lukas Mathis points out that installing Mac OS X applications is often confusing. I can’t agree more. Even as an advanced user I often find installing an application is more hassle than it could be. I realized that a long time ago and that’s why I’m no longer offering disk image downloads anymore.

How it should be

When I click on a link to download a new application, I expect to get an application in my download folder. From there, I should be able to drag it to the trash if I don’t like it, move it to the Application folder (or anywhere else) if I want to keep it, or just leave it there if I’m lazy.

How I’ve done it in the past

In the first incarnations of Mac OS X, Apple told developers to use disk images (those .dmg files) to distribute applications though the Internet. The result is as described by Lukas: you get a disk image, open it to mount a new virtual volume from which you can copy the application elsewhere, or unmount the volume and drag the disk image to the trash. And that volume is automatically unmounted upon a log out.

Well, that’s exactly what I did for my own applications at first. But since I didn’t like that practice much when installing other applications, I was searching for a better way.

Then came Internet-Enabled Disk Images. By setting a certain bit in your .dmg file, you can make the image mounter program treat the disk image as if it was an archive: it mounts the image, copies its content in the same directory your disk image is, and then moves the disk image to the trash. When moving the image to the trash, the internet-enabled bit is cleared, so if you move the file out of the trash and double-click it, it will then mount as a normal image.

I used internet-enabled disk images for my software only for a short time. As a developer, I feel they’re tricky to manipulate since they loose their internet-enabled bit just by double-clicking them.

Internet-enabled disk images provide the ideal experience described above only if your browser is set up to open the file automatically after download. By opening the disk image file with the appropriate helper (the system’s disk image mounter), the browser would provide that ideal experience and all you’d see after downloading is the application you wanted. Alas, for security reasons, few browsers do that today, and when you open manually the file you downloaded, that file disappear as a new one appears beside it, which is somewhat confusing.

Then, Safari came along and changed a few things.

How I’m doing it now

Safari’s handling of compressed files is somewhat different from other browsers. Upon downloading a zip archive, or an internet-enabled disk image, Safari automatically decompress the content it and put the archive to the trash (this behaviour can be disabled from Safari’s preferences). Remember the ideal scenario depicted above? Well, that’s exactly it: you click on the download link for the application and you get the application in your download folder, plain and simple.

Since Safari appeared, I’ve been distributing my apps in zip1 files. From the developer-preparing-a-file side, you can create the archive directly from the Finder and you’re guarantied that double-clicking it won’t disable the automatic unarchinving (as with internet-enabled disk images), so it’s safer to manipulate. Also, disk images are a little tricky to host on a web server too because the server often doesn’t know about the .dmg file extension and can’t label it with the proper MIME type; no such problem with zip files.

As a user, if you have disabled automatic decompression, or are using another browser which doesn’t automatically decompress, you’ll get a simple archive you can manually decompress and put to the trash if you want too. The downloaded file won’t go to the trash by itself and become a non-internet-enabled disk image in the process (something which I find very counter-intuitive).


Thanks to Safari, the ideal scenario works quite well, as long as you’re using one of the right file formats.

I still don’t get why some applications are still distributed on the web with non-internet-enabled disk images. Don’t developers realize they can do better for their users? Having a flashy window pop in the Finder with instructions for installing the app is more hassle for your users than just having the application appear in the download folder.

Or perhaps developers fear the user will forget they downloaded their app if when the download finish it doesn’t pop a new window with their logo in big. If that’s the problem, then perhaps Safari should stop opening non-internet-enabled disk images by itself when the download finish… In fact, now that I think about it, I wish Safari wouldn’t do that.

  1. Note that, since Mac OS X 10.3, the system unarchiver can also decompress gzip- and bzip-compressed tar archives (.tgz and .tbz files); those will get you better compression ratios than zip files and will be handled perfectly well by Safari. I’ve already began using .tbz files for things that can’t work on 10.2 anyway (mostly developer stuff). ↩︎

  • © 2003–2023 Michel Fortin.