How to Add a Database to an iPhone App Without a Backend (2026)

By Sigsten Gustavii· 27 October 2026· 8 min read

To add a database to an iPhone app, decide whether the data stays on one phone or must be shared, pick on-device storage or a cloud database, define the tables and who may read each one, and connect the app's screens to it. In a Borel app, you describe what the app should remember and Borel declares the tables, the rules and the storage.

"Add a database" sounds like one decision, but it is really two: where the data lives, and who may see it. Get those right and the rest is screens. This guide explains both in plain words, then shows how Borel builds it.

On the phone: SwiftData

For data that belongs to one person on one phone, Apple's SwiftData keeps it on the device. The app opens instantly, works on a plane, and costs nothing to run. Borel uses it for apps like a habit tracker, a journal, a budget app or a workout log; see offline data.

The trade-off: data on one phone doesn't follow someone to a new phone unless they restore a backup, and it can't be shared with a partner. When either matters, it's time for the cloud.

In the cloud: Borel Cloud

When the app needs shared or synced data, Borel gives it Borel Cloud: a Postgres database, email sign-in and file storage, run by Borel. There is no account to create with a database company, no key to paste, and no server to deploy. You don't write SQL; Borel declares the tables from what the app needs.

Who can read what: access rules

The most important part of a cloud database is the rule on each table. Borel picks one of a small set, and the database enforces it, so it holds even if someone calls the database without the app:

Groups come with invite codes and roles (owner, editor, viewer), so "share this list with my partner" is a sentence, not a project.

Changing the database later

Apps grow, and the database grows with them. When you ask for a new field or table, Borel declares the change and runs it. A field added to a table that already has rows gets a default, so existing data stays valid. Before a change to a field's type or a table's access rule, Borel saves a restore copy, and for an app already on the App Store such a change waits for you to approve it. You never type a migration by hand.

Files and photos

Pictures and documents don't belong in database rows. Borel uploads them to the app's own file storage and keeps their path in the row, and screens show them from there. Uploads count toward the app's storage costs, and a person's files are removed when they delete their account.

Common database mistakes, and how to avoid them

1. Putting everything in the cloud. Data that only one person uses on one phone is faster, free and offline in SwiftData. Move it to the cloud when sharing or syncing needs it.
2. Rules only in the app. If the only thing keeping data private is a filter in the app's code, anyone who calls the database directly can read it. Rules belong in the database, which is where Borel puts them.
3. Storing pictures in rows. Large files slow every list down. Keep them in file storage and store the path.
4. Counting on the phone. Adding up likes on the phone gets slow and wrong as data grows. Let the database keep the count.
5. Inventing sample data. Fake rows in a real app confuse people and reviewers. Borel's builder is told never to insert invented rows into a live database.
6. Forgetting deletion. When someone deletes their account, their rows and files have to go too. Plan for it from day one.

Apple's rules that touch your data

When you fill in App Store Connect's app privacy details, list what the cloud stores, such as email addresses and content people post.

What a database costs

See pricing, and Cloud cost in the workspace for what each app uses.

How to choose the right database setup

• Borel, for an iPhone app where you describe the data and get SwiftData or a cloud database with access rules, sign-in and storage, without a backend to run.
• Firebase or Supabase by hand, if you write the app in Xcode and want to manage the service, its rules and its bill yourself.
• Apple's CloudKit, if you are a Swift developer and want data in each person's own iCloud; Borel apps don't use it.
• [CatDoes](/compare/catdoes), if you need Android too; it has its own cloud for React Native apps.

How to do it with Borel, step by step

Step 1: Say what the app remembers

In plain words, list the things the app keeps, who owns each, and who else sees it. Borel decides the tables.

Keep a shared shopping list for a household. Anyone can create a household and invite others with a code. Every member can add, tick and remove items; each item remembers who added it. Each person also has private favourite products only they see. Let people search items by name.

Step 2: Check the data with two accounts

In the iOS Simulator in your browser, make two accounts. Join one household from both, add items from each, and confirm a third account outside the household sees nothing.

Step 3: Add to it as the app grows

Ask for new things in plain words: "add a quantity to each item", "keep a history of what we bought". Borel declares each change and keeps existing data.

Step 4: Publish

Stamp checks the app, and Publish builds and uploads it under your Apple Developer account. Add a demo account in a household with items so Apple's reviewer can see the shared list.

The Bottom Line

A database is two decisions: where data lives and who may read it. Borel keeps personal data on the phone with SwiftData and shared data in Borel Cloud, with access rules enforced by the database, uploads in storage and account deletion that really deletes. Describe what your app should remember in Borel and test it with two accounts on a live iPhone.

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.