iPhone, third-party applications and Settings.app

In the Mobile Human Interface Guidelines, Apple recommends putting application preferences into the iPhone's system-wide Settings application. Here are two quotes from the Mobile HIG:

Another important facet of the single application model is the way you handle application-specific preferences. On iPhone OS-based devices, users set preferences in the Settings application. Your iPhone application can supply such preferences, but this means that they must quit your application when they want to access them in Settings. If you follow the standard guidelines and offer settings that users need to set once, and then rarely, if ever, again, the user experience of your application should be smooth.

And

Among all types of iPhone applications, a productivity application is the most likely to supply preferences, or settings, the user can specify in the Settings application.

John Gruber points out that many applications ignore this rule:

One other thing I noticed might prove important when using other applications, as well. AIM's settings are not accessed within the app itself; rather, AIM adds a settings panel to the system-wide Settings app.

(...)

AOL is not being untoward in this regard; this is actually what Apple encourages iPhone developers to do. Based on the apps I've seen today, though, most developers aren't doing it. That's a bad combination – if most third-party apps display their settings screens themselves, then when users do encounter an app that uses the system-wide Settings app, they're very likely to assume that the app simply doesn't have any settings.

One of the applications not putting its preferences into Settings.app is OmniFocus for the iPhone. If you don't have the application, you can see this in this screencast. I decided to ask the Omni Group what their rationale for keeping preferences inside the application was, and the OmniGroup's Ken Case replied, saying:

Settings which appear in the built-in Settings application can't have any code associated with them, they can only use standard controls which store data in a few limited data types. We wanted to provide the ability to copy synchronization settings from a Mac on your local Wi-Fi network, which involves code – making it impossible to put our settings in the global Settings application.

The above point makes this moot, obviously, but in general another important factor to consider is whether the user might change a setting more than once or whether it's really just a one-time configuration. If you're talking about something like Mail settings, it's pretty much fire and forget – but in OmniFocus' case, the user might want to quickly switch between looking at all their completed items and then switch back to looking at just their available actions, and they wouldn't want to have to relaunch OmniFocus each time they did this.

(The built-in Settings also gives us a convenient place to put commands to Send Feedback, look up Online Help, and view Release Notes, but that wasn't a primary factor.)

This makes sense. Apple should either update Settings.app to support the features developers need, or change its HIG, telling devs not to put settings into Settings.app, but to keep them in their applications.

If Apple decides to update Settings.app, applications should put all prefs into Settings.app and turn preferences which users want to change regularly - such as whether the user sees completed items or just available actions - into "regular" application features accessible outside the application's preferences.

Either way, the current situation is confusing, as it is never clear where a particular application's settings can be found, or indeed if an application has any settings at all.