The Robservatory

Robservations on everything…


Should Apple applications be movable?

Tiger boxA 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 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 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 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)?


  1. Well ... with the addition of Spotlight, I really think Apple should try using it to locate where programs are installed instead of assuming that the apps will stay there ... the VISE installer, which is used by some Microsoft apps and Macromedia apps, has been doing this for ages.

    Personally, I'm one of those weird people who leaves everything in the Applications folder ... as you mentioned about patches, you'll never know if the program needs to be updated and has to stay in it's correct folder ...

    The only thing outside their correct folders would be the GarageBand Jampacks and the LiveType Data which I off-loaded onto an external drive and referenced back on main hard drive using symlinks.

  2. It's (somewhat) easy to do, yet it hasn't been done yet. Very likely it's simply not a priority for Apple. They'll get around to fixing it at about the same time as they improve Finder. :(


  3. Agreed that it should be better. However, the basic flaw is with the package format. As far as I can tell, everything in a package must be installed relative to a root directory. For individual application updates, this root may be "/Applications/" or "./". If it's the latter, then that application can be located anywhere; the installer will find the proper directory and set it beforehand, so the "./" will work no matter where it is.

    The problem comes with things like security patches and OS updates. They have to update things in /Applications, /usr, /bin, /System, etc, so they usually specify the root as "/", and then have to specify complete paths from that point, which means - you guessed it - "/Applications/" and so forth.

    Now, one way to solve this would be for nearly all update packages to be metapackages (like the XCode install mpkg), containing a separate installation package for each application, and a final package for the "OS" - things that truly can't move like /Library, /System, and the UNIX directories. This would likely make the packages more unwieldy to deal with, but in theory it should work.

    There would be problems, however. Keeping the search time for applications down (a combo updater may touch a couple dozen apps - this means it would have to search all over for each app), dealing with duplicates (what if I have a main partition, and an emergency partition - which app does it update?), and ensuring atomicity - that all packages are applied and not just some. It also opens the door for more bugs to creep into the individual packages.

    These problems are surmountable, and I would argue even worthwhile, but I can also see why Apple hasn't wanted to just yet (or maybe my whole understanding is just plain wrong :).

  4. Of course they should allow moving apps. If people can, some people will. And today it's not harmless : this is called a bug which needs fixing.

  5. uhm, nothing sure here, but maybe you could try a symbolic link to the Apps partition. So move all the apps, then in the terminal run 'rm -r /Applications' and then 'ln -s /Volumes/Apps /Applications'. Similar to the Users on another partition problem...


  6. A symbolic link would let you move them to another parition, but not organize them freely.

    What I do is:
    1) Check out what applications each installer package will update using Pacifist
    2) Move them back to their Apple-specified locations
    3) Run the update
    4) Move them back

    This satisfies my need to organize my apps as I see fit. It does have some problems, namely the time and inconvenience, and the inability to just use Software Update packages (as I need to do prep work beforehand).

  7. My deepest OS 10.5 dream is that Apple takes the time to rewrite Finder, improve the Dock, tighten security, and fix bugs like these. Yes, things are fine as they are. But couldn't they be better?

  8. Yes, Carl, they could be *much* better. They've spent a lot of time reworking the foundation, squeezing more and more speed, and cleaning up the internals. It's high time all of these niggling little bugs and other problems were fixed (Finder design, iPhoto performance, updating moved applications, ungainly System Preferences "organization", AppleScript support, etc). I'd actually pay for a full upgrade that just fixed everything and added back the polish and fit and finish that the Mac OS once had. That feeling that everything had been thought through, implemented thoroughly, seamlessly, and bugs were fixed quickly.

  9. The applications can't easily be moved and then referenced with a symbolic link. It might stand a better chance with an HFS Alias, but that's no good if it's on a different partition, since HFS Aliases only work on the same HFS partition (IIRC).

    The problem is that the Mac OS X Installer program (which dates back to NeXT days, by the way, not Mac OS proper) packages its applications up in a compressed format called PAX; which is rather like the Unix TAR but just different. Unfortunately, the un-PAXer engine (pax -r) will overwrite symlink'd directories and replace them with real directories instead. This has been a known bug since time began; it may have been fixed in 10.4 but I'm not expecting it to have been.

    Although most apps can be moved, there are a few 'gotchas'. Unlike comment 3 indicates, most apps don't write into /bin or /usr/bin (the only ones really being stuff like and which include command-line-compilery things). However, they can install private frameworks into /System/Library/PrivateFrameworks/ (which is a kind of Mac OS X dynamic link library, if you're interested). The iLife apps are an example of this, as are the Apple Pro tools (which use Pro Application Support, or some arrangement of those words).

    Since the app in a few cases is a shell to the underlying framework (e.g. Safari is a set of widgets around the WebCore framework, QuicktimePlayer is a set of widgets around the Quicktime framework etc.) it's not safe to just move the app elsewhere, as it will rely on the framework versions too. This is one reason why they are all bodged to install only on / in case you're interested; they have to write the app, and the framework in the OS partition there as well. For example, you can't (easily) set up on a networked share, because you also need the framework set up as well. (However, you can set the framework up on a networked share too ...)

    It's also worth noting that 'Applications' is the well-known name for putting apps in, which is why if you create a user account and put a directory called 'Applications' in, it turns into the specific icon for an Applications directory. Ditto for Library, and Mac OS X will go through a search path for finding apps:
    ~/Applications /Applications /Network/Applications (/Developer/Applications)
    as well as libraries:
    ~/Library /Library /System/Library /Network/Library (/Developer/Library ?)

    From this, it's relatively easy to create a share and mount a directory into the /Network/Applications and /Network/Library which are part of the known search path. Whilst it doesn't matter too much about the applications, it's really handy having the frameworks available in /Network/Library as well. To achieve this, you'll need a server capable of hosting shares (I use NFS; I've found AFP to be problematic at best of times, but it's getting better) and then mount them into /Network/Applications and /Network/Library.

    For example, if you have a FireWire drive that you want to put stuff in, stick them in /Volumes/MyBigDrive/Applications (and ../Libraries as well). Then, set up an NFS export (see Mac OS X hints for how :-) for /Volumes/MyBigDrive/Applications and then re-mount it as /Network/Applications; ditto for Libraries. You should then see them in the /Network tab in your drawer.

    When updates come out, you can install them onto a different 'target', although (to my knowledge) not via the Installer app itself. Download the package (Download and Keep from Software Update), then run it with 'installer -target /Volumes/MyBigDrive -pkg SecUpd_1023.pkg'. (If you want to get rid of excess languages, you can also add -lang en to only install English)

    A few of the apps (mostly the iLife ones) will attempt to complain if the drive isn't / -- but that can be fixed. There's a file called something like preinstall in the SecUpd_1023.pkg/Contents/Resources directory; there's usually something like 'if [ $drive = '/' ]; echo "You must install this on /"; exit 1' in there. Removing this line, or getting rid of the exit will allow you to install it anywhere you want.

    The other approach (and the one that Apple wants people to do) is to image a virgin Mac with the disk image utility, and then make the image available via NetBoot. That way, all macs have exactly the same image at all times; when an update comes in, you can test it on your 'virgin' mac, and then push the image everywhere. I'm not sure if these imaging tools are only part of Mac OS X Server, but given that they are just DiskUtility type 'make an image of this hard drive' it's not entirely impossible to do it outside of a Server environment.

    Of course, I've not had time to go into the /Library/Receipts folder for what you've installed where, but you might want to move the receipts into the shared /Network/Library/Receipts for the packages that you have installed on the shared drive in the past...


  10. I myself always leave in place all applications that come as packages and are installed in /Applications by Apple's Installer in that location with no choice to install it elsewhere.
    Most of the other applications I install in ~/Applications. The "Applications" folder in my Home folder is apparently recognized by the system as a Applications folder, not only gets it the Applications folder icon automatically, but also Services related to applications in ~/Applications appear in the Services menu. I localized the folder (Dutch is my language) by creating a ".localized" file in it.

  11. The Installer in 10.4 has had some pretty major improvements to tackle this issue among others—enough that it's version 2.0. At this point it's an issue of (a) whether Apple cares and (b) whether the Installer is bug-free enough to permit it (I've noticed quite a few issues of flakiness in the 10.4 Installer, most notably not installing several important files in the Xcode installer.)

  12. My basic upgrade to 10.4 went OK despite my using "Photo" "Utilities" and "Office" folders within my Apps folder. But the problem reared its ugly head when I tried to add the French localization back to these apps and got the .app broken icons throught my /App folder. iSync was completely broken after this. It is very annoying to still see this type of problem, it seems like such a 10.0 kind of issue that should just work It is completely un-mac like to think Apps cannot at least be placed in a subdirectory. They even do it themselves with the default "/Apps/Utilities" folder! The beauty of the mac is not having to have single Start Menu full of 10,000,000 items that you can't find...

  13. I think the larger problem is that we're seeing the outcome of clashes between classic Mac OS behavior and what NeXT brought to the table. In a nutshell, the classic Mac OS "way" was to never use paths and to always make the filesystem locate objects for you. This why Apple created the nice FindFolder APIs to locate specific system folders based on identifiers (in the form of four character OSType codes) and why it has nice facilities in Mac OS X like LaunchServices to locate applications. It's all to easy to rely on paths in applications but developers must resist and attempt to abstract their filesystem references away from hard-coded links and use system-supplied APIs where possible.

  14. I don't know if this is mentioned above, but in light of Spotlight I think Apple should now give no regard to the "location" of an app but instead to facilitate updates it should just use a smart folder based on the search spec of "app" meta data. Anything which is excecutable should be so designated. There can be sub-types of executable code, (to differentiate compiled versus interpreted or shell scripts, .app files, and widgets, etc), but if a smart folder is defined, then the "physical" location of these things could be anywhere.

    Now as for the UNIX underpinnings, I realize that /bin, /sbin/, /usr/local/bin, etc., cannot be a free-for-all. But for all other high-level application software, the requirement of /Applications seems pointless in a Spotlight world.

    The whole concept of "location" of files should become increasingly irrelevant to both user and developer alike -- and for the same reason -- as metadata and new search technologies mature and catch on.

  15. I run so many different apps, and I keep them grouped in sub-folders within the app folder (net/graphics/audio/video/etc). it's the only way for me to keep them all organized. Yea, it's a pain for apple updaters - so I do what others do - move the apps back to theri default location, update, then move them back. Pain, but it works

  16. When OS X first came out, I tried to organize my apps the way I had done in OS9 and earlier, until I saw the problems w/ updates and such. Now that I use QuickSilver to launch everything, I don't even look in my Applications folder anymore.

  17. I just set up a folder called "APPs".

    Inside "APPs", I set up sub-folders for "Audio", "DVD", 'Graphics', "Text", "Video", etc.

    Then I set up aliases from the applications to the sub-folders.

    I drag "APPs" to the sidebar and the dock.

    This does a few things for me:

    1. All the original applications can be found in /applications.

    2. When I want to find all the applications that deal with video, I have one place to look, no matter what strange name the author decided to name his app. (Sometimes I forget that iDIVE is actually videotape logging software.)

    3. All updates happen in /applications.

    4. I avoid having to look for the application in its folder filled with read me, history, doc and contact files.

  18. I am the same as billabOng. With Quicksilver, I can easily pack 200 apps in one Applications folder, and never worry about anything. Typing a letter or two is faster than navigating to a organized sub-folder or even clicking on an icon in the dock any way. With "instant" searching with spotlight, the dock, and programs like Quicksilver, I no longer see any point in super organizing anything, much less Applications. The only case that I could see is if you want to place your Apps on an external hard drive. I have heard that you can use Netinfo Manager to place a user folder on an external hard drive; I wonder if the same could be done with /Applications?

  19. Why is it so hard to leave applications in the applications folder? It's not a bug/

  20. The main problem I have with tools like QuickSilver is philisophical (so feel free to ignore me :). My problem is this reinforces a very Windows-like notion that we "should not" look in the file system, and just stick to our little "safe" corner, i.e. our home directory. Just ignore Applications, Library, and all those other folders. It's just like on Windows - ignore the huge unorganized "Program Files" and "Windows" directories, and above all don't look in the Registry. Windows even has those "are you sure you even want to look at this?" screens before you open those folders for the first time, reinforcing that the disk layout is largely off-limits - something to be feared, because one wrong step...

    I *like* how Apple always encouraged people to use the filesystem directly, and organize things however they pleased - at least in OS 9. Some things in OS X obviously can't move - /System, /Library, and the invisible UNIX directories. However, I really do believe that applications should be freely moveable, as should user home directories. If I'm on a single user computer and I feel like it, I should be able to make "/" my home directory and ignore the concept of "Users" if I *really* feel like it. Or I should be able to put my home and some critical apps on an iPod and take them anywhere.

  21. I don't think Apple is interested in letting users put their apps where they choose. I imagine it was quite a support nightmare for Apple in the Mac OS 9 days to troubleshoot Joe Six Pack's Mac after he moved the various Apple applications all over his hard drive. I came across many a mac with multiple instances of critical applications such as Quicktime. No wonder the Apple support personnel almost always urged you to reformat your hard drive.

    That said, I think Apple can have it's way and still give us users some flexibility when it comes to organizing our apps. Apple should install all of its apps in a folder called Applications-OSX, and then create another folder called Applications-User. This would let Apple dump all of its apps in the OSX folder and make system updates and support easy. All third party apps would be installed in the Applications-User folder and software developers would be required to search that folder and its hierarchy for their applications.

    Then as plik wrote (user 18) each user could create a local Apps folder with aliases to the apps they need and drag this folder into the dock and sidebar for easy access.

    Best of both worlds, eh?

  22. Judging by the posts by the posts by Joshua Ochs and coops, it would seem that Windows was made with the developer in mind and Mac Classic was made with the user in mind. This would probably help explain the extraneous number of bugs in every version of Windows. It would seem that with Mac OS X, Apple has (tried) to give people the best of both worlds, by keeping things organized with English names at all user levels and at initial developer levels of the file system and I assume of the OS as well, but by also making things less "movable" to the user. So the movable Applications argument really boils down to where Apple should draw the line to make things easy for both the developer and the user.

    As for Quicksilver, I don't find it Windows-like at all. Since it only opens files that have already been organized either by the user or by an installer, it doesn't discourage file-system use but rather just makes things easier. This could change in the future, but it would still be better than the Windows "see-if-you-can-find-the-program-you-want-in-a-list-of-100-by-guessing-what-it-is-listed-under" approach.

    I could be wrong about all of this as I know nothing about development for either Windows or Mac.

  23. is able to find previously installed software.

    Apple uses this technique in (most of?) its new software updates. Look for "IFPkgPathMappings" in the Info.plist file and for the Resources/TokenDefinitions.plist file inside an installation package.

  24. I suspect that opinions will be divided between people who have come to OS X from OS 9 and those who have come from another OS which is generally more restrictive.

    I used to use OS 9 which allowed you to organise your files exactly the way you wanted them (outside the System Folder) and philosophically I resent the fact that I cannot organise my files the way I want to any more. I am happy to accept that certain things have to be in the System or Library folders, stuff that I'll rarely, if ever, interact with but for my apps and my docs I should be able to put them wherever I want. It's technically possible as sometimes Apple's updates find apps that I've moved so why can't they ensure that apps are consistently and accurately located for EVERY update? Yes, there are ways round this but why should I have to modify the way I want to work when this problem could be solved simply.

    One of the strengths of Apple's OS and programs is that generally they feel like they're working WITH you rather than against you (unlike Windows). The stupidity where Apple's apps (and only Apple's apps) won't work unless they are in a specific place dictated by the app goes against this.

  25. I love the idea of having the OS on a different partion, as it makes maintinance and upgrading much easier. The only problem with that setup is when some applications install via the OSX installer, I'm not sure where files are being placed. There are 3 libraries on everyone's mac (system, everyone, user) and there are many folders in each library (application support, preferences, vendor specific folders, etc.) where various files go. When upgrading don't you have to save these files/folders? Doesn't that require knowing which ones to move and archive on the os x partion?

    Also, on another note. I like the simplicity of drag and drop for instillation and deletion, but in cases when an instaler is used, deletion is horrible! The first solution is to use the installer to uninstall the app, which is confusing and counterintuative at best. Often this is not an option, and so I drag and drop the app into the trash, probably leaving files I don't need on my computer, just rotting away space. Windows has a good idea with the uninstall utility.

Comments are closed.

The Robservatory © 2021 • Privacy Policy Built from the Frontier theme