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.

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...

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.

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...

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…

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.

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.

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.

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.

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

Ha! You're right. My mistake.

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.

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.

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).

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 :)

"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

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

@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.

Great stuff. Thanks!