Portable Applications on Mac OS X

The Unofficial Apple Weblog asks why Mac OS X doesn't have portable applications. That is, applications that can be carried around, complete with the user's preferences, on a USB thumb drive. It's possible for developers to do this, it just opens up a can of worms.

In Cocoa and CoreFoundation, developers don't have to think about where or how preferences are stored. NSUserDefaults abstracts you from all of that. This means a lot less bugs and a uniform preferences format. It also means that preferences are neatly integrated with Cocoa bindings.

Now a developer could step aside all of this and implement their own preferences system, but there are some things to thing about.

One: Where do you put the preferences file? Some might think the application package is a good place, because then it means the prefs are always with the app. The downside is that the preferences are always with the app. If a particular setting gets munged or the plist becomes corrupted somehow, you've got an app that won't work.

In Mac OS X, the app package is sacred. It is suppose to remain prestine at all times so that the user doesn't have to dig into the package, traverse various directories and start mucking around with things they don't understand. It's much nicer (though still not perfect) to just move the plist file and re-launch. Users don't want their application icon to just "break."

Two: We know what happens when developers start implementing their own preferences scheme. It's chaos. This is how unix/linux worked for years and years, and arguably it still works this way in some places. This sort of thing is completely not okay for a consumer computer.

Three: Preferences aren't not necessary an island. On Mac OS X, system services and applications are much more likely to be integrated in some way. So seperating the preferences for a single application might only partially get you where you want to go. What about your keychain, for example?

The Solution

If portable applications are to be a reality on Mac OS X and to work properly (not just a hack), it's almost certainly something Apple will have to implement at the NSUserDefaults level. This is the beauty of an abstracted API, though. Apple can add the functionality without breaking existing applications.

Now, this could possibly be done without Apple's help, but it would have to be the result of a lot of developers agreeing on a single framework, in the same spirit as Growl. The most important thing is that we don't have everybody running around, making up their own preferences scheme. That's a mess for developers and (more importantly) users.
Design Element
Portable Applications on Mac OS X
Posted Oct 12, 2006 — 18 comments below




 

Jon Hess — Oct 12, 06 2046

One thing comes to mind, user preferences are just that, user preferences. If you take an application to a different machine, there is probably a different user... hence, different user preferences.

ssp — Oct 12, 06 2047

While I guess, people might come up with some way to fool the defaults system into using a different folder for its job, the problem would remain that applications have the bad habit of spilling their files all over your library folder (application support, caches, own folder right in there, ...) and those will be even hader to cover.

I'm wondering whether you couldn't solve the problem by having a disk image on your memory stick that you union mount over the current home (or library) folder. That way you'd catch all the changes and be able to take them with you.

Of course that's not quite as easy as just launching an application because you'll have to run some script first but on the other hand it should work for all applications and whenever you start carrying things like your preferences and files around you may want to store them in an encrypted disk image anyway...

Carl — Oct 12, 06 2048

Couldn't users just do this themselves by making an AppleScript that creates symbolic links in the ~/Library to files on a thumb drive? Sure, it would be a small pain, but it wouldn't be that hard to do. I think the number of users who are interested in this is small enough that there's no need for more than this "hack" solution to the problem.

dc — Oct 13, 06 2050

ssp's idea above seems like a pretty good one. It could even be as simple as portable-aware applications looking at mounted drives for a "Library" folder. If they detect a different set of preferences on some drive, they could prompt the user if they would like to use those settings instead. (Perhaps this could be done automatically if there is no extant application support folder for the app, as would usually be the case on lab Macs. This could possibly be a security risk--set up an Adium account to point to your own personal Jabber server, trick someone into mounting a disk image containing those prefs, prompt for their account password... 0wned! Hey, it could happen.) Applications that support portability could have a menu item to "save portable preferences" or some such, which would automatically copy the correct files to the drive. The home machine versions of these apps automatically detecting the presence of a device with portable preferences, and syncing them when necessary, would be icing.

Alternatively, and perhaps a little cleaner, apps which wanted to implement this functionality could offer an "Export Portable App" menu item, which would create a special version of the program containing all relevant preferences. Perhaps this portable app could do something clever like override the default framework's NSPreferences implementation and point them to its own app directory, or maybe something as simple as symlinking the relevant files in the host machine's ~Library folder to the app bundle on the drive.

This latter one could be a problem if the app already exists on the host machine. And, as mentioned above, if someone wanted to give a friend their copy of say Adium, it would be a definite security issue to include their preferences. You could do something simple to discourage this: changing the app icon (the original icon, dangling off a keychain?) and name ("Bob's Adium") to remind people that this is a special Adium. To avoid security problems, perhaps a portable app could detect if it was being run off the boot volume, and in that case delete the stored preferences and start from scratch--though that might result in unexpected behavior in certain use cases.

I like the simplicity of encapsulating the portable app in a single app icon. Changing the icon and name of portable apps, and including some kind of syncing functionality when connected to the original host machine, would be a very Mac-like way of doing it.

So hey, you programmers, implement it already! Having this capability in Adium/Colloquy in particular would be fantastic. A portable address book is obviously indispensable. Portable iCal, NetNewsWire, Safari/Firefox, Mail (or, failing that, Thunderbird)--all fantastic. I'm a big fan of WriteRoom; copying it to a thumb drive and knowing that all my current writing projects would be with me at all times (and autosynced with my main computer) would just be a godsend. How about a portable version of iTunes which sets up an SSH tunnel to your home Mac, and fools itself into thinking all your music is local? *That* would be cool, though probably beyond the scope of this project.

Anyway. Great idea. Apps on the Mac are so almost portable, it's such a small step to actually getting them there...

Christian Machmeier — Oct 13, 06 2051

I don't know, if it's just me, but I don't like portable applications very much. I'm not very pleased by the thought of carrying around "my" preferences because of several security issues. Don't think right about getting stolen the USB drive, but do I know exactly which personal information is stored where? Just as a weak example :) What about taking a browser to a different machine, logging in to amazon.com or ebay.com or something. Do I know exactly where my credentials and other private data are stored? Just a thought…

dc — Oct 13, 06 2052

Some kind of encryption at the preferences level might be good. Use some good symmetric cypher to password-protect the prefs. OS X is pretty good about keeping keyloggers from capture authentication passwords, if I recall correctly. Of course there's always going to be some level of risk when you use someone else's computer.

lbaum — Oct 13, 06 2055

Preferences must not sit in the application package because: (a) there are several users on each machine, all using the same applications and (b) regular users have no write access to the application package.

Moreover, they must not be stored in hidden .something files in the user's home either, for obvious reasons. That's the first thing someone porting a Unix/Linux application should learn.

lbaum — Oct 13, 06 2056

There seems to be an encoding problem in your comment system. My nickname is "Ölbaum", with a capital O umlaut that got axed when my previous comment was posted.

Matt Tavares — Oct 13, 06 2059

Actually, NSPreferences and NSPreferecnePane are the graphical front end to editing preferences. The actual data is stored in ~/Library/Preferences and is accessed through objective c with NSUserDefaults.

Scott Stevenson — Oct 13, 06 2060 Scotty the Leopard

Actually, NSPreferences and NSPreferecnePane are the graphical front end to editing preferences

Ha! You're right. My mistake.

Blain — Oct 14, 06 2070

Perfect timing! I was just reading up on NSUserDefaults, and remembered, "Didn't they say something about a command line defaults domain?" Sure enough.

So this sounds like a small utility project, which, given an application, uses the command line or standard Cocoa calls to retrieve user settings, possibly present the check-boxed list of which ones to make portable, and to generate a command line tool that calls the binary with the appropriate arguments.

The 'portablized' application itself is untouched, as the file is external text. No funky new inconsistencies on where to store the data, and if it is trashed, there is no loss. It's likely that the settings will even be portable between different versions of the app, if they maintain the same UserDefaults tags. All cocoa apps would support it out of the box, since this is an OS-level thing. And from the looks of things, the temporary changes will not affect actual user settings. Best yet, no .plist transport/library surgery required!

All that remains is to see if it would work the same on carbon apps.

Lemont Washington — Oct 15, 06 2076

What about mirroring your preferences on dot mac? That way when your loaded onto another machine you could simply retrieve the settings from dot mac and then write them into a new preferences file on the new system. It
makes you reliant upon .mac, but not a bad way to solve it. Too bad .mac isnt free.

Eric Wing — Oct 16, 06 2078

Great article. On point "One", you omit an even more serious problem about putting the preference file(s) in the app bundle: security.

Assuming you could still properly handle the multi-user paradigm correctly by placing multiple files in the .app bundle, you still require user write permissions to things in your app. You might be able to set up the directory structure such that only user write permissions are granted to the preferences files, but this presents additional problems. In multiple user situations, you have to prevent (malicious) users from being able to look at, modify, and corrupt other user preferences. Assuming you could pull this off, I think the solution is very messy (sticky bits?, access control lists?) and probably begging to be cracked.

And on fortified systems where Applications are placed in areas that are write-only, this is going to be a problem since the user shouldn't be able to create any files at all.

There are also Unix paradigms where you install different things to different partitions on your disk (for administration and/or security purposes). In this paradigm, you install applications to its own partition (and possibly mount it as read-only, and could also be a network mount), and you minimize the amount of free space on this partition. Assuming you didn't mount the partition as read-only and let users write to it, the small amount of free space could become a problem if enough users create enough large preference files to eat up all the disk space (which itself can be considered a form of attack).

gand — Oct 17, 06 2083

OS X Portable Applications
Having a portable application on your external drive have the advantage that you have not to install it when you are away from your machine (at school, work, customer). Preferences are stored inside the bundle as user is not missed up by other "strange folders". Your is the drive, your is the app, your are the preferences.

Mozilla application can be started with a flag that set the preferences path, all other use symlink hack.
Security issues remain when keychain is used (but this happen also using local apps on a machine that is not your), or your drive is stolen.

Some apps use Keychain (Camino (but can be disabled), Adium, Cyberduck) but generally a window ask you to save password to keychain. Mozilla apps don't use keychain and other don't need it (gimp, inkscape, OOo...).
Nothing is perfect :)

Sir Henry — Nov 07, 06 2322

"Why Mac OS X doesn't have portable applications?" Euh ... and what if MacOS X allready has portable apps? That's what it seems reading this article just published by MacWorld:

Your apps in your pocket | Mobile Mac
------------------------------------------------
Imagine carrying the applications you use all the time—a Web browser, an e-mail client, a word processor, and even an image editor—in your pocket, ready to run on any Mac (and in some cases, Windows PCs), with all your preferences and plug-ins just the way you want them. Welcome to the world of portable applications.

Read the article : <http://www.macworld.com/2006/10/secrets/novmobilemac/index.php>

And allso check this webpage:

"OS X Portable Applications"
<http://www.freesmug.org/portableapps/>

Prettige dag ("have a nice day" in Dutch)!

Sir Henry

Yelo — Feb 11, 08 5469

I've been thinking in the lines of some kind of "wrapper" software. You fire upp the wrapper (that resides on your usb stick) and choose the .app (ie Mail.app) from within this software and it automatically redirects all data that wants to be saved to your Library home dir to a dir on the stick. Sounds good, don't know how one'd do it though...

http://www.sandboxie.com/index.php?PortableSandbox

Scott Stevenson — Feb 11, 08 5472 Scotty the Leopard

@Yelo: it automatically redirects all data that wants to be saved to your Library home dir to a dir on the stick

Offhand, I can't think of a reliable way for a third party app to implement that.

CMS design — Dec 29, 09 7050

Great stuff. Thanks!




 

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.





Copyright © Scott Stevenson 2004-2015