When we talk about app settings we could mean a few different things. The actual settings values which are stored by your app, an in-app method to view/edit those settings or the iOS Settings UI which exposes both system and application settings to the user in the centralised place.
In this article we’ll look at the last of these. If you are creating a cross platform app you’ll probably never look into this as the main place to store your settings because you’ll want a consistent UI within your app to expose settings. The iOS Settings app will always have an entry for your app anyway as this exposes permissions which your app has requested and allows the user to change their preferences. You may have also noticed that when debugging your Xamarin app you’ll see entries added here for the Xamarin debugger.
In my previous blog post I wrote about visualising screen taps in your app in order to capture video walkthroughs. I decided I didn’t want the option for this exposed via the apps own Settings page, and I wanted to be able to set it before even launching the app, so I looked into adding it to this menu. As it turns out it is actually quite easy. I’m going to assume you use the NSUserDefaults mechanism for storing the underlying setting value. You might use this directly or via a cross-platform API such as Pontoon to abstract this away behind a common API.
First you need to create a folder within your Xamarin iOS project called “Settings.bundle”. Within this, you add an XML file called “Root.plist” and set the Build Action to “BundleResource”. This XML file is in Apple’s horrible “Property List” XML format and contains a dictionary with a single entry with the key “PreferenceSpecifiers”. The value if this is an array of dictionaries, each of which represents an individual preference item. Here is my example adding a single Boolean toggle:-
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
This give you the simple output shown below. The section header with your app name is added for you. Here you can see each entry defines the setting type (which affects other options available), the display text, the key (which is the name of the setting in code), and the default value (of the correct type for your setting).
There are other type specifiers for other settings types such as text or selections from multiple fixed values. You can read more details here.
While this might seem a bit disconnected from your app you can open this settings page programmatically. Useful not just for showing the user these custom settings but also if you want to assist the user in turning an app permission back on. There is a hard-coded Uri to launch your app specific settings page which you can call using:-
Some 3rd-party apps make extensive use of this to display app settings and properties. Take a look at Microsoft Word which uses this mechanism to display product version and licensing information as well as app settings. How much you intend to integrate with it is entirely up to you, but it can help your app feel more integrated when it offers these kinds of hooks into the OS.