There an interesting debate which is going on since many years about how Mac apps should be distributed an installed. Back in September John Gruber wrote this interesting piece, outlining the pros and cons of three popular formats of delivering Mac apps: .zip, .dmg and installer. He was inspired by this post where Alexander Limi (founder of Plone, working at Mozilla now) discussed the problems of the installation process of Firefox on the Mac platform.
In this post I’ll discuss all the possible scenarios, referring to other articles found on the web to give you my idea of how Mac applications should be distributed.
Mac apps usually come into a .dmg file you download from the developers website. A .dmg is a virtual disk image which usually contains the .app file (the application itself) and an alias of the /Applications folder. Together with these two files there’s the illustrated background (a trend many designers are following) and the instructions “To install, drag to the Applications folder”. From a “human interface” standpoint the situation is pretty clear: you have an application, a folder and some instructions telling you that you have to drag that file to install it. I think this way of distributing apps is wrong. First, one of the reasons why Mac OS is popular is because you don’t have to do anything to install an application: people say “you just have to download it”. That’s a lie.
In the .dmg situation above, you have to follow 6 steps:
- Download the file;
- Bring the mounted .dmg on front (don’t know why Safari auto-mounts .dmg in the background)
- Drag the icon to a folder;
- Unmount the .dmg;
- Trash the .dmg;
- Find the application and launch it
Common Problems
This is not exactly “anything”. Sure, everything can be performed in 15 seconds after the download, but still this method requires the user to act instead of just waiting for the OS to do it. Moreover, there could be some problems within the process itself.
Limi says:
“very few new users that recently purchased their first Mac know how to do this”
“many people don’t read these kind of instructions at all.”
“Some common errors that we have seen repeatedly among informal testing with friends and family are:
They drag the application to their dock directly.
This creates a link to the file inside the disk image, which means that every time they try starting Firefox, the disk image is unpacked and mounted, and starting of Firefox becomes very slow, which makes it a bad experience.
They think that starting Firefox is done by opening the disk image every time.
This is very common, and the logic is that the first time they started Firefox, they had to do this, so they continue doing it. This makes starting Firefox a chore, since it takes a lot of clicks to accomplish.”
So, there are 3 main problems: people don’t know the process, people ignore the instructions, people don’t understand the instructions. While I can understand people who don’t know the whole process at all (and here comes Apple, which should provide better instructions on the first run of Mac OS X) the fact that they ignore/misunderstand the .dmg file is relevant: either they are stupid or delivering applications in this way is simply wrong. And given that many bloggers are talking about this problem, I believe users are not that stupid. Anyway, it seems like many users (after the .dmg is mounted) just want to start the application: this is perfectly right.
Why should I do something more to correctly use an app?
So they go dragging the icon in the .dmg to the dock or, even worse, they think they have to open a .dmg every time.
Let’s make a step backward. Why is necessary to pack applications in .dmg files? Here’s what Patrick Dubroy said in 2007 in his post “Why is installing software on a Mac so complicated”?
“On the Mac, an application is like a file — you can save it anywhere you want, and deleting it is as simple as dragging it to the trash. But the problem is, they aren’t really files, they’re folders. So in order to distribute them as a single file, they have to be wrapped in a .dmg or some sort of archive. And this is where the problems begin.”
It’s very likely that you didn’t know this, a Mac application isn’t really a file, it’s just a bundle. Try to “Show Package Contents” on an app icon and see it by yourself. They’re folders which Finder treats as single items (Gruber). So that’s why an .app file has to be wrapped into a package.
.zip and Installers
This leads me to two other ways of delivering Mac apps: .zip files and Installers. That of zipping an application into an archive is a trend many developers are following and which seems easier to understand for the end user. You download the .zip archive, Safari extracts it and you have the application in your Downloads folder.
Gruber says:
“Just like with disk images, what users should do then is move the app to their Applications folder. But — and this is the advantage of using a zip archive over a disk image — they don’t have to. Users can just launch the app right from their Downloads folder, and it’ll work just fine. They can drag it to their Dock, and it’ll work just fine. It’s not tidy, but there’s no confusing abstraction like a virtual disk volume that will disappear after they log out for reasons they don’t understand.”
But this is not exactly right: first, having dozens of applications into the downloads folder could make the Applications folder itself useless and unnecessary. And, you’ll still have the original .zip file to trash. But most important, an application located into the Downloads doesn’t work just fine.
Application-provided services only work if the application is stored into the Applications folder. (link)
Indeed, I made a quick test about this. I downloaded Pukka which comes packed into a .dmg file. The .dmg auto-mounted, displayed the user agreement, extracted Pukka.app to the Downloads folder and auto-trashed the .dmg file. Cool. Basing on what Gruber said, we should be able to use Pukka just fine right now. That’s not true. Pukka has some specific Services (like “Send Url to Pukka”) which will activate only if the app it’s into /Applications. Otherwise, they won’t be there.
But, I found out that if you leave the application in the Downloads folder and you run it the Services will install fine. So it’s not that big problem after all, but still - isn’t perfection. For the record, simply moving the app to the Applications folder without running it installs the related Services. (You should also read this post from Andy Kim of the PotionFactory, where he says .zip archives can cause the application to crash for not loading resources)
Then, Gruber talks about installers. Here’s an excerpt:
“What I don’t like about installers is that users don’t know what’s been installed where. (Yes, you can use the Show Files command in the installer File menu to see what’s going to be installed, but the only people who know about this command are those of us who aren’t confused by any of this stuff in the first place.)
… On the Mac, installers are considered at least slightly unconventional. Whenever I install a Mac app by drag and drop, I don’t put it in the root-level-of-the-startup-drive /Applications/ folder, but instead in the inside-my-user-account-home-folder ~/Applications/, just as a simple way of keeping third-party apps separate from Apple’s system apps.”
He’s perfectly right, I don’t like installers too. They seem the port of the massive long installation setup that happens on Windows, which involves a ridiculous amount of “are you really sure about this” security prompts. And again, Jesse Ruderman says “they indicate that an application will require elevated privileges” while Limi seems to appreciate installers that run when a disk image is mounted. Definitely, I’m not up for package installers: they don’t let the users know what’s happening, they just scary people making them think the application is heavy and “different”. And this is not so good for OS consistency.
So, we should find a universal way of delivering Mac applications.
Here’s my idea:
- Application comes packed into a .dmg file;
- You download the .dmg;
- Mac OS auto-mounts the .dmg and brings the window on front;
- No aliases, you just have to double click the app’s icon;
- As you double click it, a dialogue box asks you if you want to move the app to the Applications folder;
- Dmg is unmounted and trashed;
- Application launches.
With this process the users just have to:
- double click to install;
- choose where the app will be stored.
..which makes a 2 steps process. Sure, the OS should do everything else in the background and there should be support for the dialogue box thing. Fortunately, Andy Kim thought of this problem and released the public code that handles the app moving process. The dialogue box itself is very self explanatory, and doesn’t require the users to think too much about it. Seems like the guys at Spotify got it right are using a very similar process to mine, which auto mounts / unmounts / trashes the DMG and let the user double click to install. I think Mozilla too decided to let the users install Firefox like this.
In the end, it’s up to you, developers, to choose a universal method of delivering your applications. You just can’t keep on delivering your apps in 20+ different ways, it’s ridiculous and not-user-friendly. This “double-click process” seems the best solution so far, but I’m open to suggestions and ideas.
Resources:
How Should Mac Apps Be Distributed?
Making it easier to install Mac apps
Improving the Spotify installation experience
Improving the Mac installer for Firefox
Why is installing software on a Mac so complicated?
Firefox Mac installation experience, revisited
Installing Applications on the Mac is Broken
Installing Applications on the Mac: Still Broken
