The settings used to be in the Settings app
Should third party iPhone app settings be placed in Apple’s Settings.app or should they be contained within the app itself?
Although this issue has been covered quite a bit previously, our interest was reignited by Tweetie 2’s shift from using Settings.app to in-app settings. Loren (Tweetie’s developer) has previously been a strong supporter of keeping settings in Settings.app.
It’s been 15 months since the App Store opened, so what’s changed? What patterns or new opinions have emerged?
The argument for placing settings in Settings.app
Easy to implement. It’s the quickest and easiest method for adding settings to your app.
Consistency. It makes sense to keep settings for everything in a centralized location with standadized UI, provided all or most third party developers use Settings.app. Unfortunately, they don’t.
It’s recommended by Apple. Great care has been taking to build a strong language for design elements and workflow on the iPhone, so recommendations made by Apple should carry a fair amount of weight with third party developers. Stepping outside Apple’s guidelines might mean you’re placing unnecessary hurdles in your app’s usability. There’s a fair amount of ambiguity though:
“iPhone applications can offer settings that define preferred application behaviors or configuration options users can set to change some functionality of the application. Settings that define preferred application behaviors… are accessible in the built-in Settings application. Configuration options should be available within the application context…”
Differentiating between “preferred application behaviors” and “configuration options” sounds like a difficult task. If an app has both, should settings be split between in-app and Settings.app? And what about Apple’s Keynote Remote and iTunes Remote apps… they both have in-app settings that feel like preferred application behaviors. Messy.
The argument for placing settings in inside your app
Changes can be reflected instantly. Users don’t have to quit the app, open Settings.app, change settings, then reopen the third party app to see any changes.
Higher visibility. In-app settings are typically easier for users to find than settings contained within Settings.app. What’s worse, the store has been split between the two, exacerbating visibility issues. John Gruber realised this would be an issue from day one.
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.
Dynamic code. In-app settings can do anything the author desires. Settings within Settings.app can’t contain conditionally visible controls, audio playback, custom controls or other dynamic components.
No Settings.app bloat. Due to the large amount of apps some users have on their iPhones or iPod touches (up to 180), placing everything in Settings.app is likely to cause unmanageable clutter and lag as Settings.app opens. This feels completely unsustainable for the future, where we’re all likely to have even more apps installed.
We contacted several developers for comment on the topic. Most have worked on projects with settings that used to be in Settings.app, but are now inside their app.
Loren Brichter talking about Tweetie
“The tipping point for me was the fact that you can’t execute code in the Settings app. I needed this in Tweetie 2, as I had to check credentials (for Instapaper and such).”
“In my mind, the perfect app has no settings—it works perfectly for the user out of the box. The more settings you have means the more you’re probably doing wrong (or you’re just trying to pander to everyone… stop right there… it’s not worth it).”
“That’s why I thought having Settings in a dedicated app made sense… it was out of the way, and only contained stuff that you’d ‘set and forget’. You’d never have to stare at a settings button in every different app all of the time.”
Mark Jardine talking about Weightbot & Convertbot
“Aside from the obvious reasons like some users not being able to find the settings or know they even exist, some of the settings in our apps are things people need to change often. And you usually decide to make the change while you are already running the app. We’d hate for users to have to quit our app, go to Settings.app, and then back to ours again to see the changes. Not only that, the settings in our apps happen to be important to the core functionality (especially Weightbot). If users didn’t configure the app before using it, it would display incorrect data.”
Sophia Teutschler talking about Groceries & Tipulator
“It’s a little drama with Settings on the iPhone. The Settings.app is a great way to get rid of the “set and forget” settings bloat in your app. But it’s current “static” form doesn’t allow more sophisticated implementations needed for setting up accounts. Moreover, most users simply won’t find them”
“The best advice I can give at the moment is to get rid of settings altogether. Trust me, your app UI will shine if you really really try.”
Marco Arment talking about Instapaper
“Fundamentally, I love the idea of putting all settings in the Settings app, but in practice, it just doesn’t make sense for third-party apps. Not only do the technical limitations prevent many apps (including Instapaper) from realistically using it, but I’d guess that there’s a big support and reputation cost for people who can’t find the settings or assume there aren’t any.”
Russell Ivanovic talking about Pocket Weather AU
“We received several emails a week from people asking for features that were already part of our application. We finally gave up and moved the settings into the application. We felt vindicated when we saw all the 5 star reviews about the amazing new features we added, all of which had been there in previous releases.”
Piotr Gajos talking about Night Stand
“We receive tons of support e-mails everyday: feature suggestions, ideas, bug reports, impressions etc. It sums up to a huge knowledge database and overtime trends appear. One of them has been consistent from the start and very simple: we want settings inside Night Stand! How could we not cave in? We design our software for our users and even though we hold Apple’s Human Interface Guidelines close to our hearts, they are still just guidelines. People are more important. Of course it wasn’t an easy decision, we waged pros and cons for a long time.”
“…it all boils down to convenience and simplicity. It simply feels better and right to have Settings inside Night Stand. I’m not saying it’s a universal rule, obviously it doesn’t apply for all iPhone/iPod touch apps. We are lucky that Night Stand has a fairly simple UI to begin with and ‘i’ button in bottom-right corner of the screen does not introduce too much clutter.”
Felix Lamouroux talking about Trails
“The settings app is very limited. We wanted a UISlider and other UIKit elements which would not have been possible. In-app settings are easier to find and the app can provide contextual help that depend on selected settings. It’s also the only way to provide presets to help users find the right settings. Users can select a preset and see the impact on settings.”
Hwee-Boon Yar talking about SimplyTweet
“It was my intention all along to have all SimplyTweet settings within the Settings app. It has changed recently, and (only) the push sounds settings are in-app for practical reasons. There’s no way to preview sounds if that setting is placed in Settings app.”
Eric Singley talking about Yelp
“Initially, putting settings into the global Settings app seemed to be the best practice. But over time, three things happened: 1. you started seeing settings in-app more often, 2. I got the sense that very few average users knew about the outside-the-app settings 3. as our app grew, we started to add more important settings options we wanted people to find. So for these reasons, it made sense to give settings more prominence by pulling them into the app.”
Alex Pretzlav talking about Yelp
“Additionally, we added the ability to fill one of our app settings automatically from the iPhone’s current location and our API, which can’t be done via the settings app.”
If you do opt for in-app settings, which icon should you use?
Unfortunately, there are at least two common icons used by developers to open in-app settings. Apple doesn’t seem to have much in the way of recommendations, beyond using an info “i” in their own Weather and Stocks apps, as well as macOS’s Dashboard Widgets.
Info. Used by Apple, so it feels like the most official solution, although it doesn’t seem very attractive when used in a Tab Bar. Used by: Weather, Stocks, Weightbot, Convertbot, Night Stand and more.
Cog. Although macOS uses a cog icon for contextual action menus in Finder, Mail and other apps, it has a strong association with options, so it can be a good choice too. Used by: Things, iStat, Beats, Darkness, Pocket Weather, Twittelator, Trails and more.
Settings text. If you have space in a Navigation Bar or Toolbar, why not remove all confusion and use a text-based button? The only negative is that space can be at a premium, so not all apps have the luxury of using such a large button, especially if you need to allow extra width for localisation. Used by: Keynote Remote, iTunes Remote, Tweetie 2, Twitterrific and more.
Some free artwork
We’ve created an icon care package for the Photoshop-challenged. It includes scalable vectors as well as Tab Bar and Toolbar sized bitmaps. Feel free to use them in your own projects.
Bjango settings icons
The lesser of two evils
It seems like the trend is swinging in favour of in-app settings, but both solutions are more than acceptable. If possible, maybe the best solution is to have no settings at all.