How to add a settings screen to an app without shipping a junk drawer.
To add a settings screen to an app, list every value a person is allowed to change, then sort each one into three piles: kept on the device, kept on the account, owned by the operating system. The screen itself is a grouped, scrollable list and takes an afternoon. The sorting is the real work, and getting it wrong is what makes an app settings page feel broken six months later. The visual conventions are the easy half and they are covered in app design basics.
The honest limit first. A preferences screen in a mobile app cannot grant an operating system permission. Your notifications switch does not turn notifications on, and once somebody has answered the system prompt with no, the only truthful thing that row can do is show the current state and open the system settings app. Everything below is about the other rows: which ones you need, where each value is stored, and the one row both app stores require.
Plan your own rows firstThe short version
A settings screen is not one feature, it is three storage decisions in a list.
Device, account, operating system. A theme choice belongs to this phone. A display name belongs to the person and should follow them to a new phone. Camera access belongs to iOS or Android and your screen can only report it. Most settings bugs are a value filed in the wrong one of those three.
The build decision follows from the same split. If every setting is device only, the screen is a day of work and no server. The moment one value has to follow the account, you need somewhere to put it and a rule for what happens when the write fails.
Every setting lives in one of three places
Sort the list before you draw anything. Device settings belong to the handset: a theme, a default sort order, whether the map opens in satellite view. Account settings belong to the person: display name, email, which emails they want, anything they would be annoyed to set up twice. System settings belong to the platform: notifications, location, camera, microphone, contacts, photos.
That third pile is where designs go wrong, because your screen can show the state but cannot change it. Apple's documentation says the first authorization request prompts the person and records the answer, and that later requests do not prompt again. It also tells you to check the authorization status before scheduling anything, because people can change it at any time. So a correct notifications row reads the live system status, shows it in plain words, and offers a button that opens the system settings app. A switch that silently does nothing is worse than a sentence of text.
For the first two piles, decide sync per setting rather than once for the whole screen. A local value is instant, works offline and vanishes with the phone. An account value survives a reinstall and a new device, but costs a network call every time it changes. Sort order can stay local while notification preferences follow the account. Deciding where a preference is stored is a schema question, and it is cheaper to settle before the screen exists than after.
The rows almost every app needs
Settings screens converge on a short list, so start from it and delete what does not apply rather than inventing from scratch. Account: name, email, sign in method, sign out, delete account. Notifications: what you send, plus the door into the system settings. Appearance: light, dark or follow the system. Data and privacy: what you collect, an export if people create anything worth keeping, and the privacy policy. Support: contact, help, and the version number.
The version number earns its row. It is the first thing a support reply asks for and the cheapest line on the screen, so put the build number beside it and let people tap to copy. Anything the support team has to ask for twice belongs here.
Account rows are where a settings screen stops being switches and becomes a small product of its own. Changing an email needs a verification step. Changing a password needs the old one. If people have a profile at all, the edit form usually sits one tap away from this screen rather than inline, which is a separate job: see add user profiles for the fields and the upload.
Resist the urge to park every unfinished idea here. A settings screen with forty rows usually means four features were never designed.
Try it
Which rows your settings screen needs
Turn on what your app already does. The list on the right is the screen, top to bottom.
6 rows
- Profile and email
- Sign out
- Delete account
- Help and contact
- Privacy policy
- Version and build
Delete account is on the list because both app stores require it once people can create an account.
Account deletion is a store requirement, not a nice to have
If people can create an account in your app, you have to let them delete it from inside the app. Apple put this in App Store Review Guideline 5.1.1, announced it in October 2021 with a January 31, 2022 date, then extended the deadline to June 30, 2022. It has been in force for app submissions since then. Apple's own wording is that the option should be easy to find, and that only offering a way to temporarily disable or deactivate an account is insufficient.
Google Play asks for the same outcome from the other side. Its user data policy says an app that lets people create an account must give an in app path to delete the account and its associated data, and also publish a web link where the same request can be made. The web link is the half teams forget, because it lives outside the app they are building.
The design consequence is small and specific. Delete account is a row on this screen, at the bottom, visually separated, behind a confirmation that says in plain words what disappears and what is kept. Some apps have to retain records for legal reasons, so name those on the confirmation rather than burying them in a policy nobody opens, and check your own obligations before writing that copy.
Build the real thing while you are there. A delete button that hides the login and leaves every row in the database is the version that fails review.
Apple Developer News, deadline for in-app purchase and account deletion requirements extended
Write the rows so people can read them
A settings screen is read, not explored. Group rows under short headings, keep every label a plain statement, and never make somebody work out what off means. Email me about new comments is a label anyone can answer in a second. Comment notifications is a guess, because off could mean no email, no push, or both.
Destructive rows get different treatment from the rest. Separate them from the group above, name the verb in the label, and confirm. Sign out is recoverable and deserves one tap. Delete account is not recoverable and deserves a sentence, a second action, and no default button that a thumb finds by accident.
This screen is also the easiest place to fail a contrast or tap target check, because a column of small grey labels looks calm in a design file. Rows have to stay reachable with a thumb and readable at the largest text size the platform offers, which is what breaks when a label runs two words longer than the mockup. The rules are short and boring, and they are collected in app accessibility guidelines.
Four ways to ship the screen
| Approach | Survives a reinstall | Works offline | Covers account deletion | Rough effort |
|---|---|---|---|---|
| Device storage only | No | Yes | No | an afternoon |
| Device storage plus an account record | Yes | Yes | with a server route | a few days |
| iOS system settings bundle | No | Yes | No | an hour, low discoverability |
| Your auth provider's hosted pages | Yes | No | depends on the provider | hours, looks like someone else |
| Generated, then edited by hand | Yes | Yes | if you ask for it | minutes to a first version |
Building the screen instead of hand writing the list
This is the most copied screen in mobile software and it still takes a day by hand, because it is thirty small decisions rather than one big one. Grouped list, navigation rows, switches, a destructive row, a confirmation sheet, a read of the live notification status, and the wiring behind each value.
Newly is an AI app builder. You describe the app in plain English, it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. Asking for a settings screen with the rows above gets the grouping, the switches and the delete account confirmation in one pass, and the code stays yours: a ZIP from Settings, the CLI, or two way GitHub sync from the Deploy tab. It is $25 a month and there is no free plan.
It will not make the platform decisions for you. No backend ships with it, so whether a preference follows the account is still your call, and deleting an account for real still means deleting the rows behind it.
Questions people ask about settings screens
Account rows first: name, email, sign in method, sign out and delete account. Then notifications, appearance, data and privacy with an export if people create content, and support with contact, help and the version number. Delete anything that does not apply rather than adding rows nobody asked for.
Describe the settings your app actually has
List the values people are allowed to change, say which ones should follow them to a new phone, and build the screen around that.
Start building