What is it?

InAppSettingsKit is an open source solution to to easily add in-app settings to your iPhone apps. It uses a hybrid approach by maintaining the Settings.app pane. So the user has the choice where to change the settings. More details about the history of this development on the FutureTap Blog and the Edovia Blog.

How does it work?

To support traditional Settings.app panes, the app must include a Settings.bundle with at least a Root.plist to specify the connection of settings UI elements with NSUserDefaults keys. InAppSettingsKit basically just uses the same Settings.bundle to do its work. This means there's no additional work when you want to include a new settings parameter. It just has to be added to the Settings.bundle and it will appear both in-app and in Settings.app. All settings types like text fields, sliders, toggle elements, child views etc. are supported.

The License

We released the code under the liberal BSD license in order to make it possible to include it in every project, be it a free or paid app. The only thing we ask for is giving the original developers some credit. The easiest way to include credits is by leaving the "Powered by InAppSettingsKit" notice in the code. If you decide to remove this notice, a noticeable mention on the App Store description page or homepage is fine, too. To gain some exposure for your app we suggest adding your app to our list.

How to include it?

The source code is available on github. A sample app shows how to integrate InAppSettingsKit into an application.

Depending on your project it might be needed to make some changes in the startup code of your app. Your app has to be able to reconfigure itself at runtime if the settings are changed by the user. This could be done in a -reconfigure method that is being called from -applicationDidFinishLaunching as well as in the delegate method -settingsViewControllerDidEnd: of IASKSettingsViewController.

Some little extras

The intention of InAppSettingsKit was to create a 100% imitation of the Settings.app behavior. However, we added some bonus features for extra flexibility: When searching for a settings plist "xyz.plist", we first check for a "xyz.inApp.plist" and use it if available. This allows overriding the settings file that is used in-app. For example, Where To? uses this mechanism to change the wording of "At next start" (for resetting confirmation dialogs) to be appropriate if the app is already running. Secondly, the labels in the settings table use a variable font size, especially handy to squeeze-in long localizations (beware: this might break the look in Settings.app if labels are too long!).

More information

The Dr. Touch podcast has an interview with Ortwin Gentz about InAppSettingsKit.