In our eyes there are a lot of good reasons to take the in-app route:
- Settings.app becomes a total mess with more and more apps and takes long to load all apps
- Most users simply don’t understand the mechanism and miss the settings if they are only placed in Settings.app
- A context switch is needed to switch between settings and the app. If the app happens to be on the 16th screen, this involves quite some tapping and flicking.
- In-App settings can instantly change the behavior of the app
On the other hand, some (albeit a minority, we feel) users are used to the mechanism of Settings.app. Also, being part of Settings.app gains some user exposure and apps included there are viewed as first-class citizens by many advanced users.
So how can this dilemma be solved?
Many apps decide to get rid of a Settings.app pane altogether. Interestingly, all user-installable apps from Apple are amongst them (Remote, Keynote Remote, MobileMe iDisk). Further examples are Twitterrific, AIM and countless others.
We’re proposing a second approach that we call “hybrid settings”. In this model, the user has the choice: the settings are available in Settings.app. But they’re placed in-app as well. That way, every user can decide where to edit the settings. The in-app settings are a 100% clone of the Settings.app style.
How does it look like?
Well, the settings look exactly the same as in Settings.app. This consistency does make sense if we don’t want to confuse our users. In TouchPad, a “Settings” button shifts in the settings dialog. In Where To?, the settings are entered by tapping on the i-icon on the top right of the first screen. The settings then appear with a nice flip animation known from Weather.app or Stocks.app. Alternatively, a navigation push or a tab bar can be used.
Can I integrate this in my app?
At first, the solution was developed by Luc Vandal of Edovia and Ortwin Gentz of FutureTap because we both had the need. So we wrote this piece of software as a Canadian-German co-production. Then, we thought twice and felt the code might be useful for some other folks. So we decided to release InAppSettingsKit as open source. We hope it will be adopted widely.
Comments are closed.