Share this story

The iPhone offers a centralized preferences system through its Settings application. In the iPhone SDK, you can create and customize Settings bundles that let you install custom preference panes into the Settings app. These settings are synchronized into the NSUserDefaults system and can be retrieved and read from your program.

It's an elegant approach that allows you to forgo the extra design needed to create and maintain settings screens from within your program and to focus your design work on application semantics. There's only one problem: most users may never see your settings. Ever. The conceptual separation between your program and the Settings app seems to prevent end-users from discovering, let alone updating, those preferences.

There are currently two big trends among developers. Some have pulled preferences out of the Settings app entirely and put them directly into their programs. Other developers mirror the preferences, letting users access them from within the application as well as from Settings. These developers are responding to help tickets from users who just aren't aware that the Settings application affects third-party products, as well as built-in Apple ones.

Putting the settings back into the application helps leverage user expectations. The conceptual separation between the centralized preferences and the third-party application has not yet been effectively bridged by the SDK. The SDK should take its cue from the behavior of some semi-documented Apple Info.plist settings.

When developers set SBUsesNetwork and UIRequiresPersistentWiFi and no network is available, a built-in dialog offers to take users to Settings. This is an explicit button link, which users can click. The SDK needs to support this same kind of bridging if developers are going to use external settings bundles. At one point, the iPhone supported the prefs:// protocol, but that has since been disabled. Perhaps Apple should revisit that approach, letting the settings bundles be referenced from directly within the program.

Once bridged, it would also be nice to have some sort of return functionality that allows users to resume whatever tasks they had left in order to address their settings. Because if the bridge simply dumps you outside the program with no way to return, it introduces yet another way to lose friends and alienate users.

I could easily see this kind of external link being extended beyond settings. The current SDK supports external URL calls to Safari and Mail. Integrating a bridging function to allow short visits to view a web page or pop off an email (with attachments, preferably) could really enhance the user experience with a minimum of extra overhead from Apple.

Until Apple moves forward on this, providing a developer-controlled Settings link on demand, I expect developers to continue to abandon centralized settings. With no way to access settings bundles screens directly from applications, it makes sense at least in the short term for devs to add preferences directly into programs and bypass the Settings application.