A quick entry tonight, just because the subject came up recently in this hint regarding iSync. In particular, the hint (and comments) note that iSync will fail if the application is moved into a directory whose name contains spaces. I had added an editor’s aside about moving apps in OS X, and my personal belief that it’s a Bad Thing to do. As noted in the second comment, it’s not necessarily an issue with using applications — they’ll (more than likely) run fine from most any location. Instead, it’s an issue with Apple’s updaters failing if the application they update isn’t in the usual spot.
Although it’s my philosophy not to move Apple’s applications around in OS X, that doesn’t mean I’m happy about it. I have multiple partitions on my drive (partition vs. don’t partition; that’s a subject for another day!), and have one set up particularly for all my applications and utilities (called Apps). I put everything on that partition — it makes it easier, for instance, to erase and install OS X if I have the need. As of result, the only things you’ll find in my boot drive’s Applications and Utilities folders are Apple’s programs, along with anything that just won’t run if it’s located elsewhere (Tony Hawk Pro Skater 4, for instance, fails if it’s not in /Applications). Everything else lives on my Apps partition. As much as I’d love to move Apple’s stuff out of there, after reading about the issues people have had with upgraded applications not working, I’ve decided to just let sleeping Mail applications lie.
It’s not just major upgrades that cause issues, but minor upgrades as well. If you’re not familiar with the problem, it goes something like this: User moves Mail to their “Other Apps” folder, perhaps on another drive. Apple releases a security update that includes a Mail patch. The installer merrily adds the patch data into the Mail.app bundle in Applications. It’s no problem if this bundle doesn’t exist; the installer just creates it. When the update is done, the user is left with a new Mail bundle (which doesn’t work, of course), containing only the patched code and support files. This doesn’t seem to happen with every application update, but it clearly has happened a lot, and to a large number of users. Time will tell if 10.4 continues to have the same issue.
But my point in writing isn’t really to describe the problem. It’s to ask “why do we still have this problem?” Way Back When, Mac applications could be installed anywhere. If a patch came out for something, after waiting eight hours for the 50MB file to download on your 14.4KB modem, you’d launch the installer and it would either work automatically, or ask you where the original application was located. Many years have passed since then; connection speeds have greatly increased (thank goodness!), and yet, we’ve regressed on the patch process. We have machines that can find thousands of files “instantly” … but can’t find a program bundled named Mail.app on the hard drive? I admit, I’m not a programmer, but (a) other installer packages (i.e. Microsoft Office) seem to do this quite well, and (b) how hard can it be to add some logic that says “Hey, there’s no Mail.app in /Applications. Perhaps I should ask Spotlight if there’s a matching version of Mail elsewhere, and then ask the user if they’d like to patch that version.” Or even just pop up a dialog asking “Would you like to update Mail in /Applications, or some other location?” But no. Instead, the installer just does its thing, tells the user that all is well, then quits. And, of course, all is not well — the original application is unpatched, and the bits installed in /Applications are non functional.
This whole process seems very non Mac-like to me, and I keep hoping it will improve with future OS updates. So far, I’m still waiting. Am I wrong in thinking this should be a trivial fix for Apple? If so, any theories as to why they haven’t done so as of yet (to my knowledge, at least)?