Installing Applications on the Mac is Broken

When recently visiting my parents, my dad asked me to help him install Firefox on his Mac. He was able to download the application just fine, but actually installing it proved a bit more confusing. The reason for this is that installing applications under Mac OS X is essentially broken.

How it used to be

Installing apps on a Mac used to be simple. In Mac OS 9 and earlier versions, you would typically download a StuffIt file. All Macs came with StuffIt Expander, which would open the .sit file, put the contained application or a folder with the application in its place, and remove the .sit file. You could then simply use the application right where it was, or you could move it somewhere else. That is not the case anymore.

How it is today

Apple probably realized that relying on a third-party application for installing apps was not a good idea. So they stopped bundling StuffIt Expander with Mac OS X. Instead, developers started to abuse images to deliver downloadable applications. Nowadays, most Mac applications come on .dmgs. After the user downloads the application, Mac OS X mounts the image. The user is then supposed to drag the application to the applications folder, unmount the image’s volume and throw the .dmg to the Trash. This is too complicated. Most “normal” Mac users don’t understand that the application on the mounted .dmg is not really on their system. They start the application from the .dmg and end up confused when it disappears after a restart. To fix this, developers started adding instructions to the mounted dmg’s window. Here’s how’s Adium’s mounted image window looks:

The picture is supposed to show the user that he should drag the Adium icon to the Applications icon. Of course, this is still too confusing for many users. Even worse, it doesn’t work like this for all applications. Here is the mounted image window for the aforementioned Firefox:

If you thought you could actually drag the Firefox icon to the Applications folder icon, well, tough luck. The Application folder icon isn’t actually an icon at all, it’s part of the background image. The idea is that you open a second window and drag the Firefox icon to the second window’s Applications folder.

These are more than two kinds of Mac “installers.” Google (among other companies) rolls its own installation thing. Adobe uses a third-party for its installers, which are often less than perfect. Some applications use what Apple confusingly calls “internet-enabled images.” These are images which, upon double-clicking, replace themselves with their content and then move the .dmg file to the Trash. Obviously, Apple saw the issue with images and tried to fix them, but only managed to create additional confusion. And of course, Apple doesn’t use any of these solutions. Apple generally delivers its software as normal .dmg files with files which start Apple’s own installer application. Some applications have now started alerting the user when they are launched from a mounted .dmg, asking whether they should move themselves to the Applications folder.

All told, installing applications on the Mac has become inconsistent, confusing, and just plain broken. It’s time for some kind of usable standardized consistent behaviour to emerge. Perhaps having the application work as its own installer, asking the user whether it should move itself to the Applications folder if it’s launched from a .dmg (and afterwards ejecting the .dmg, and launching the installed application, as wel as optinally installing an icon in the Dock), would be a good first step.

Addendum: Michel Fortin, author of the excellent Sim Daltonism, a color blindness simulator which I use to test user interfaces for “compatibility” with color-blind people, has an article on the subject. His solution is to provide applications as downloadable ZIP files. Safari will open such files automatically, replicating how Mac OS used to work before OS X. This is a reasonable solution; the issue I see with this is that downloadable .dmg files have trained people to expect some kind of window showing the new application to open automatically. Downloadable ZIP files simply place the application in the downloads folder, where the user may then promptly forget about them.

Addendum 2: Versions, a Mac Subersion client, throws up a dialog box saying “Versions is downloading, you’ll find it in your downloads folder.” after you click on the download link. The download itself is a ZIP file. Quite a neat solution, I think.

April 6th, 2008 / Tags: mac os x, apple, installer, firefox, adium, user interface, usability / Trackback

Apple's Photoshop Killer

Three days ago, Adobe announced that Photoshop CS4’s 64-bit version will only be available on Windows. There won’t be a 64-Bit version of Photoshop for the Mac until CS5.

How Mac OS X came to be

First of all, I want to make it perfectly clear that this is not Adobe’s fault. Apple has brought this upon itself, and to understand how this has happened, we need to go back a few years to the time befor Mac OS X. In the early 90s, Apple was in a bad position. Its operating system was technically outdated. Several projects inside Apple, and several joint-ventures with other companies aimed at creating a successor to Apple’s operating system had failed. Apple was essentially forced to either buy an existing solution, or license an operating system from Microsoft or Sun. Apple didn’t want to become dependent on a third-party operating system, so they had to buy an OS. At the time, there were two options: Be’s BeOS and NeXT’s OPENSTEP. Apple bought NeXT in 1997, bringing Steve Jobs back to the company as well as giving it a new operating system.

Soon thereafter, Apple announced its plan: Developers were basically forced to rewrite their applications in Objective-C for NeXT’s object-oriented, comparably modern APIs and frameworks, or “Cocoa,” as Apple called that part of what would become Mac OS X. Third-party devs were understandably not pleased at all. In particular, Apple relied on two third-party applications: Microsoft Word and Adobe Photoshop. Without these two applications, Mac OS X would be stillborn. Given Apple’s financial position at the time, chances were they could not survive such a disaster.

The Plan

Microsoft and Adobe must have made it pretty clear to Apple that they were not going to rewrite their applications for Cocoa, because soon after its first announcement, Apple changed its tune. In addition to Cocoa, there would be a second API called Carbon. Carbon is essentially a port of the old, procedural pre-OS X Mac APIs. Using Carbon, developers could easily port their old Mac applications to Mac OS X without having to rewrite large parts of their code.

When the first end-user version of Mac OS X came out in 2001, it didn’t take too long for native versions of most important applications to come out, and all was well for Apple.

64 Bits

Today, we are looking at a similar transition as the one from Mac OS 9 to Mac OS X, albeit on a different level. For the last decade, most computers used 32 bits to address blocks of data in memory. Since each address has a fixed length of 32 bits, the number of individual addresses is limited. As memory has gotten bigger and bigger, computers are starting to run out of addresses for the individual blocks. To allow computers to address larger memory spaces, they are switching to using 64 bits for each address.

To cope with these larger addresses, operating systems as well as applications have to be updated. As late as 2006, Apple’s story was that they would upgrade both Carbon and Cocoa to 64-bit versions, allowing all Mac applications exist as 64-bit versions. Adobe thus worked on a 64-bit version of Photoshop. Last June, Apple pulled the rug out from under them by killing the 64-bit version of Carbon.

This leaves Adobe with a year of wasted effort and no easy way to create a 64-bit version of Photoshop.

I want to make it perfectly clear that I do not think that Apple’s intent was malicious in any way. Recently, there has been quite some evidence that Apple’s engineering is understaffed. In order to finish the iPhone in time, Apple pulled engineers from Leopard and had them work on the iPhone, which lead the Leopard’s delay. It is obvious that Apple either simply found out that they did not have the resources required to finish 64-bit Carbon in time, or thought their developers’ time would be better spent working on something else.

So now Adobe is forced to throw away some of their work and rewrite large parts of Photoshop in Cocoa, which isn’t a small task by any means.

How can Apple afford to do this?

So how can Apple do this? Back when they moved from Mac OS 9 to Mac OS X, Microsoft and Adobe were able to force Apple’s hand. Why don’t they have that power anymore?

Apple learned a lot from that time. It’s a lot less dependent on outside developers today.

Microsoft

When looking at Microsoft, first of all it’s important to keep in mind that a 64-bit version of Office isn’t really needed. Office doesn’t have to cope with documents sized in the multi-gigabytes. Office works perfectly well in 32-bit Carbon, and will continue to do so for decades, if Apple keeps 32-bit Carbon updated.

Second, there’s iWork. While iWork isn’t a perfect replacement for Office, it works really well for many people. Today, it’s possible to use a Mac that is free of Microsoft applications in almost any environment.

Adobe

Adobe is a tougher nut to crack. While Apple has been competing with Adobe on many fronts such as video editing or photo management, they don’t have a Photoshop killer.

What Apple has been doing for the last few years, however, is create APIs that make it easier to create Photoshop-like applications. Using Apple’s Core Graphics frameworks, developers can create rudimentary graphics applications within days, and even small teams can create applications that, even today, can replace Photoshop in many cases. Pixelmator, to name one, was created by one single developer and one single user interface designer. Even in its first version, it does many things that Photoshop does. It even does a few things Photoshop doesn’t do. More importantly, it is improving quickly. While Pixelmator currently still lacks many features Photoshop users take for granted, there are new Pixelmator versions with more features almost monthly.

Here’s another thing Apple has done: Its popular photo management software Aperture now supports plugins. There is nothing stopping a third-party developer from adding an image editor with many of Photoshop’s features right within Aperture.

As Apple continues to improve its graphics frameworks, it won’t need to create its own Photoshop competitor, because it will have an army of third-party Photoshop competitors.

This, I think, is why Apple was able to simply kill 64-bit Carbon: For the last decade, it has worked hard on becoming less reliant on Microsoft and Adobe. Delaying the 64-bit version of Photoshop by a year or two won’t hurt Apple at all.

April 5th, 2008 / Tags: appler, aperture, photoshop, lightroom, mac os x, mac os 9, carbon, cocoa, adobe, microsoft, word, iwork, iris, acorn / Trackback

Code Signing on the iPhone and on Mac OS X

Mike Ash of Rogue Amoeba has written a fantastic article about code signing, and about how Apple is using it in Mac OS X and on the iPhone.

if Apple doesn’t sign your iPhone app, it does not run. Even for local development, you need to get the code signed. The iPhone SDK is free, but by itself it won’t let you load apps onto an iPhone. When you pay Apple the $99 to enroll in the program, they send you a certificate which can be used to sign your applications. However, they will only work on iPhones which have been provisioned with this certificate.

Actually, if you haven’t already, stop right here and go read the article. Don’t worry, I’ll wait.

Done? Good.

Personally, I don’t mind Apple signing applications they sell on the iPhone app store. What I do mind is that Apple does not give me a way to write code, run it unsigned or self-signed (with a non-Apple certificate) on my own iPhone, and give it (again, unsigned or self-signed) to my friends who have iPhones. In other words, I want to be able to sign code with a non-Apple certificate, and I want a way to tell the iPhone to accept all code signed with a given certificate, even if that certificate has nothing to do with Apple. There are several reasons for this.

First of all, I recognize that Apple is under no obligation to make it easy for me to run applications on the iPhone. Still, I think it’s wrong for a company to serve as a gatekeeper, imposing its own morals (if a company can even be said to have morals) on the users of its devices. A technology company should enable people, not disable them. Telling its users what applications they are allowed to run is ultimately hurting them, and hurting progress. While I can understand that media companies have an incentive to hurt progress, tech companies should avoid going down the same road; in the end, it will only hurt themselves.¹

Second, it hurts the iPhone. Apple’s guidelines effectively disallow many perfectly legal applications. In his article, Mike mentions porn. Porn is an important market force. It’s no coincidence that pornographic web sites make up a huge part of all web sites, and pornography makes up a large amount of all internet traffic. I understand that Apple doesn’t want to sell pornographic material on its store, but by not allowing Apple-unsigned code to run on iPhones, they’re not only keeping porn out of their store, they’re keeping porn out of the iPhone entirely². And this is not the only genre of applications affected; Apple’s guidelines forbid applications which run in the background, which affects things like social networking software, VOIP clients or chat applications. By keeping these apps out of the store, Apple keeps them out of the iPhone; many groundbreaking applications which could have made the iPhone a rule changer are effectively forbidden because the iPhone only runs code signed by Apple.

Third, it’s bad for application quality. Typically, developers run beta tests to find bugs in their applications. How can a developer run a beta test if running code on a beta tester’s iPhone requires that the code is signed by Apple?

Finally, how do I send review copies to magazines, or free copies of my app to friends?

Requiring code to be signed by Apple is a dangerous path to follow. Unfortunately, Apple already seems to have plans to require signed code on Mac OS X. That, by itself, is quite inconvenient, but not necessarily a bad thing; it gives users the security of knowing where code comes from. However, requiring code to be signed by Apple even on Mac OS X would be a tremendously bad move, and would probably ultimately hurt Apple, its developers, and its users.

Update: Rogue Amoeba has now started filing bugs against these restrictions. Good idea.

March 8th, 2008 / Tags: iphone, sdk, code signing, mac os x, apple, rogue amoeba software, mike ash / Trackback

dotfiles vs. the invisible bit

When trying to engage people in a text you’re writing, a common approach is to introduce the concept you’re discussing using a narrative, a short story vaguely related to the topic at hand. Joel Spolsky is a master at this. He used to serve in the army, so he often introduces articles by starting with an army story. Hey, I can do that, too, I also did military service! ¹

I used to serve as a medic and driver. This is probably the most laid-back thing you can do in the army. In a combat situation, medics, especially those who are also drivers, are typically not risking their lives, so there’s no need to drill them until they put the word of their commander above their need for self-preservation. Doing service as a medic is akin to working in a highly professional, focused company; hierarchy doesn’t count for too much.

As it turns out, we did not have enough lieutenants in our corps. Strangely, we ended up getting a lieutenant from the infantry. Needless to say, he thought his infantry approach to leading worked everywhere, and promptly started his first day by yelling at us, which was greeted by blank stares, followed by roaring laughter. At first, the poor fellow was rather confused by our insubordination, but he eventually figured out that talking to people worked a lot better than yelling at them.

The point of all this is that just because something seems to be the same doesn’t mean that it is.

Most operating systems support the concept of “invisible files.” Basically, an invisible file is a file that the user can’t see using the standard file browser. But the similarities end there.

Unix —— On many Unix-like systems, files whose name starts with a dot are not shown to the user. Obviously, users can easily add dots to names and make files invisible. Just as easily, they show invisible files again. Typing

ls -a

in the Terminal will list all files except for . (the current directory) and .. (the parent directory). Other than not being shown to the user by default, files starting with a dot typically behave just like every other file.

In other words, this is a way for the user to get rid of clutter; to make files she doesn’t normally want to see invisible. It’s a way to trim down long file listings, so only relevant files are shown.

Mac OS 9 and earlier —— Apple also had invisible files in their pre-OS X systems. Whether a file was invisible was defined by its meta data. To make a file invisible, a bit could be set on the file. That would make the file invisible in all views; in Mac OS 9, there is no built-in way to see invisible files, or to make them visible.

In other words, invisible files in Mac OS 9 were a way for the system to hide files from the user. Typically, these were files that the system needed; files which the user was not supposed to see or tinker with. The invisible bit was a flag which allowed the system to keep files away from users.

Mac OS X —— So when Apple bought NeXT and started working on OS X, they came upon a problem: On the one hand, OS X was supposed to be a Unix-like system. It has the BSD subsystem, it has a Terminal, it has ls -a.

On the other hand, it also had to support many concepts from Mac OS 9. HFS, Apple’s file system, wasn’t going anywhere. The invisible bit was still there.

So, like the infantry lieutenant yelling at medics because that’s all he ever knew, Apple decided that Unix dot files should behave like Mac OS 9’s invisible files. And just like that, files starting with dots were not visible anymore.

Unfortunately, this is a bit of a problem. While Apple took the concept of hiding files whose name starts with a dot from Unix, they left the semantics from Mac OS 9 intact. In other words, files which the user made invisible behave as if the system didn’t want the user to touch them. In fact, Mac OS X actually prevents you from starting a file with a dot:

And if you do manage to start a file name with a dot, you’ll never see the file again using Apple’s default software. This is just plain user-unfriendly. It’s my system, and I should be able to use whatever name I could possibly want.

Apple took the Unix syntax for invisible files, but kept the Mac OS 9 semantics.

The Problem ——

Why is this a problem? Because dotfiles and invisible files are not the same. Here’s an example:

Due to reasons I might some day discuss in another article, Mac OS X stores some meta data in files named .DS_Store.² Many folders in Mac OS X contain such a .DS_Store file. .DS_Store files sometimes contain names of files stored in the folder.

As you can see from the name, Apple intended .DS_Store files to be invisible. These files are not supposed to be seen or opened by users. So Apple put a dot in front their name. Unfortunately, they originally neglected to also set the invisible bit. This becomes an issue if you do something like using an FTP client to mirror a local folder to a network. The FTP client might not know that the .DS_Store file is supposed to be invisible, thus happily copying it to a public web server, where it can then be opened and viewed by anyone. Obviously, it’s typically not a good idea to publish file listings on the Internet. Soon after the issue became public, Apple set the invisible bit, and developers creating FTP clients changed their code so dotfiles were ignored during mirroring.

Which, of course, isn’t the right thing to do, either.

Often, server configurations are stored in dotfiles. These are files that are supposed to be editable by administrators, and they are supposed to be mirrored to servers, but they start with a dot because you typically only edit them once, and then leave them be. An example of such a file is “.htaccess”, which contains directives telling the web server Apache such things as which directories are password-protected.

Changing FTP clients to ignore dotfiles means these files are not mirrored to the server anymore. Which means that if an administrator decides to upload a password-protected directory, the directory may be password-protected on his local installation, but mirroring it to the server will only mirror the directory’s content, and leave it unprotected on the server.

As has become obvious, many issues stem from Apple’s decision to treat dotfiles and files with the invisible bit set the same, when in reality, they are different concepts.

dotfiles are files the user wants to be invisible. Files with the invisible bit set are files Apple wants to be invisible. One is a way for users to manage their files. The other is a way for Apple to prevent users from accessing files. Mixing the two concepts only causes problems and confusion.

The proper solution would be to treat files starting with a dot just like every other file. Let users start files with dots. Don’t make them invisible. If a file needs to be invisible, set the invisible bit. Like the infantry lieutenant who had to stop treating medics like infantry soldiers, Apple should accept that forcing everyone to adhere to their vision may end up being detrimental.

February 24th, 2008 / Tags: invisible files, dotfiles, Apple, Mac OS X, Mac OS 9, Unix / Trackback