883 words on Mac OS X
This text on Mac software distribution has made the rounds. It starts by stating the obvious: that software coming on disk images has the potential to confuse novice users – and goes on to suggest the ridiculous: that software should figure out whether it is running from a disk image and, if it is, it should copy itself to the Applications folder.
Not only do I think this idea is annoying and Microsoftesque – it’s my computer, nothing should copy stuff around unless it’s absolutely necessary and well explained or I give the order to do it. I can also easily come with situations where doing this may not be technically feasible. Just the install location itself – top level Applications, the under-advertised user level Applications or possibly the rare network Applications folder will be a mystery. As will be figuring out where you have sufficient access rights and so on.
But what gets people to suggest such an ‘install’ behaviour is that they have a wrong picture of the situation in their head. A picture which includes applications being ‘installed’ and one that supposes they should be in a certain folder on your hard drive when there is no reason for either of those things. An application is just a file (well, technically a bundle, blah, blah) which will launch when it is double clicked. It can be pretty much everywhere on your hard drive. And keeping their applications anywhere on their drives is pretty much what Mac users have been doing since the mid 1980s. So why not let people do just that?
Luckily, the vast majority of Mac applications will run from anywhere on your drive (although Cocoa still has enough static path-based brokenness inside it to make a few things buggy if you move an application while it is running – something I often do with applications I try after downloading and then decide to a more permanent location) and no ‘installation’ of any kind is needed. The only problem we have is that unlike those clever Windows executables, you cannot download a Mac application as a single file from the web such that it runs without further ado.
Of course OS X’s bundles are to blame for that. And I don’t think they are a good idea for anybody but developers. With applications often containing many localisations and help books these days, there can easily hundreds if not thousands of files for a single application. A fact that makes copying an application or even telling its size a rather slow thing. Why couldn’t they just tar or zip the bundle up and enable the system to run those?
Because of that, all Mac applications need to be unpacked in some way (which isn’t really new for Mac users as resource forks created a similar situation many years back). And a common way to do that is to put the application on a disk image. Apple have pushed that way of distributing software for a long time. I assume because initially it was the only easy way to pack your Mac files in a way that all the things from resources to permissions survived reliably.
And it appears that Apple realise the inconvenience of those disk images because they also introduced the ‘internet-enable’ command on one of their tools which makes Safari automatically copy the application you downloaded out of its disk image, place right into your downloads folder and dump the disk image when it’s done. Thus making things user friendly again. Developers who think they need to use a disk image and don’t use this option are somewhat user hostile (and often vain enough that they need their own disk image with its own graphics &c).
In the past years Apple also started supporting the zip format reasonably well in their OS. And unless you need to cater for old OS X versions, there should only be few situations in which you cannot simply zip your application up – which Safari will then automatically unpack after downloading the archive.
Thus, on current systems, we have two options to make sure your application makes it to your users unharmed. One is an internet enabled disk image. The other is a simple zip archive. Both have small advantages and disadvantages. Disk images are harder to create and more compatible. They are also slower and slightly less reliable (I have seen situations where OS X refused to mount a disk image and I had to restart before I could access the volume on that image). Zip archives are very simple and fast. Usually you don’t even notice when Safari uncompresses them while the whole effort of mounting a disk image, copying hundreds of files and unmounting it again – all while the user might even interfere with what he sees in the Finder isn’t exactly user friendly. However, the compression in zip files tends to be slightly worse than what you can achieve with disk images.
And thus you have a simple choice to make. If bandwidth is an issue, disk images may be preferable. But if convenience is more important, you’ll want a zip file. And then you’ll know it ends up where downloads belong and your users can just do whatever pleases them with the file…