Should iPhone app settings be placed in Settings.app or included in-app? — There has been quite some debate on that topic and we don’t want to repeat everything all over again.

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.

InAppSettingsKit in Where To?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. Check out InAppSettingsKit.com for more details. This site also lists all apps currently using the framework and we hope it will be adopted widely.

5 Comments

  • Simon Albrecht

    wrote on January 13, 2010 at 6:03pm

    How can I move my existing Settings to In-App and remove the ones, that are in the Settings.app, without loosing the settings ?

  • Ortwin Gentz

    wrote on January 13, 2010 at 6:44pm

    Simon, the actual user settings continue to be accessed via the standard userdefaults mechanism. InAppSettingsKit only offers a UI to edit these settings from inside the app. So the place where these settings are stored is exactly the same. We just add another way to edit them.

  • Simon Albrecht

    wrote on January 13, 2010 at 6:58pm

    @Ortwin

    Thanks for your reply. Just subscribed to this blog, that I can stay updatet 🙂

  • Simon Albrecht

    wrote on January 13, 2010 at 8:40pm

    EDIT:

    @Ortwin

    Is there a way to hide the whole UINavigationBar not just the BarButton? And where is this method to dismiss the view, so I can set up my own button to dismiss the view.. 🙂

  • Ortwin Gentz

    wrote on January 13, 2010 at 9:14pm

    I don’t recommend hiding the navigation bar as it’s needed for child panes and multi value choosers.

    The Done button sends a -dismiss: message to IASKAppSettingsViewController. However, you as the caller are responsible to actually hide the settings view. You should do that in the delegate method -settingsViewControllerDidEnd:

    Check out the Sample app for details.

Comments are closed.