How to Add Login and User Accounts to an iPhone App (2026)

By Sigsten Gustavii· 27 October 2026· 8 min read

To add login to an iPhone app, decide whether the app really needs accounts, choose how people sign in, connect a backend that stores accounts and each person's data, build the sign-up, login, reset and delete screens, and give Apple's reviewer a demo account. In a Borel app, you ask for accounts and the backend and screens come with them.

Accounts are one of those features that looks like two text fields and turns out to be a week of work: email checks, forgotten passwords, sessions that expire, data that must stay private, and Apple's rule that people can delete what they made. This guide explains the choices and Apple's rules, then shows the steps in Borel.

Does your app need accounts at all?

Apple's Guideline 5.1.1(v) starts with a question: if your app doesn't include significant account-based features, let people use it without a login. Many apps don't need one:

When data only lives on one phone, Apple's SwiftData keeps it there, and the app works offline; see offline data. Add accounts when data has to move between devices or between people. Stamp, Borel's reviewer, also flags sign-in placed in front of things that don't need it.

Ways to sign people in

This matters for Apple's Guideline 4.8. An app that uses a third-party or social login, like Google, for its main account must also offer an equivalent login that limits data to name and email and lets people keep their email private, which in practice usually means Sign in with Apple. An app that uses its own email and password accounts, as Borel apps do, is not using a third-party login service, so 4.8 doesn't ask for a second option.

Where each person's data lives

An account is only useful if the app keeps each person's data apart. In a Borel app, data lives in Borel Cloud, a Postgres database Borel runs, and every row records who owns it. Borel declares an access rule for each table:

• Private: only its owner reads it, like a journal entry.
• Everyone signed in reads, the owner writes: like a public profile or a post.
• Followers read: posts for the people who follow someone.
• Members of a conversation read: messages.
• A shared group reads: a family list people join with an invite code.

These rules run in the database itself, not only in the app, so one person can't read another's data even by calling the database directly. You never write a security policy; Borel writes it from what the app needs. More on databases and backends in the glossary.

Apple's rules for apps with accounts

Delete account must really delete. In a Borel app it removes the rows the person owns and the files they uploaded, then the sign-in itself, and it works even if the app owner's balance is empty. Read the full rules on Apple's App Review Guidelines page.

Good sign-in screens

1. Let people look before signing up, so they know what the app is.
2. Ask for an account at the moment it matters: saving, posting, syncing.
3. Show password rules up front, not after a failed try.
4. Write errors in plain words: "That email and password don't match."
5. Put Forgot password next to the password field.
6. Keep Delete account findable in settings, next to the privacy policy.

What accounts cost

There is no separate auth service subscription. See pricing.

Keeping accounts safe

Most account problems are small habits, not clever attacks:

• Never put secret keys in the app. Anything inside an iPhone app can be read out of it. Borel apps hold no keys; they reach Borel Cloud with each person's own session.
• Enforce rules in the database. A check in the app's code can be skipped; a rule in the database can't. Borel's access rules live in the database.
• Confirm emails. A confirmation code stops people signing up with someone else's address.
• Collect less. Every extra field is something to protect. Apple's Guideline 5.1.1(iii) asks for the same thing.
• Protect private apps on the phone too. For a journal or a finance app, a Face ID lock keeps a borrowed phone from opening it.

How to choose the right way to add login

• Borel, if you want accounts, private data rules and account deletion in a native iPhone app without setting up a backend.
• An auth service wired by hand, such as Firebase or Supabase, if you write Swift in Xcode and want to manage the service and its rules yourself.
• [CatDoes](/compare/catdoes), if you need the same accounts on Android; it has its own cloud for React Native apps.
• No accounts at all, if the app's data can stay on one phone. Often the right answer.

How to do it with Borel, step by step

Step 1: Decide what needs an account

List what a signed-out visitor can do and what needs an account. For a recipe app: browse recipes signed out; save favourites and share a shopping list signed in.

Step 2: Ask for accounts

Add accounts. People can browse recipes without signing in. To save a favourite or join a family shopping list, ask them to sign up with email and password, confirm with the emailed code, and pick a display name. Add Forgot password. Favourites are private to each person; a shopping list is shared with family members who join with an invite code. Put Sign out and Delete account in Settings.

Rivet adds the screens and the tables with their access rules, and Borel creates the app's database if it doesn't have one yet.

Step 3: Test with two accounts

In the iOS Simulator in your browser, create two accounts. Save a favourite in one and check the other can't see it. Join the shared list from both. Reset a password. Then delete one account and check its data is gone.

Step 4: Publish with a demo account

Create a demo account with some data in it for Apple's reviewer and add it in the publish flow. Stamp checks that Delete account is there before you submit.

The Bottom Line

Accounts are worth adding when data must move between devices or people, and not before. When you do need them, Borel adds sign-up, login, confirmation and reset codes, private data rules in the database and a Delete account that really deletes, all from one message and with no backend to run. Open your app in Borel and ask for accounts.

I started Borel because I wanted to make iPhone apps without a Mac or a team behind me. If this helped you build something, I would love to see it.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.