One workflow, built two ways
If you are commissioning an app, one early decision is where its data lives: only on the user's phone, or on a server you pay for. You do not need to know databases to make that call. You need to know who uses the data, on which devices, and what happens if a phone is lost. This guide puts those questions in buyer terms.
Take a simple job: a self-employed tradesperson logs each work trip (date, start, end, purpose) and exports a monthly summary for their accountant. The screens are almost identical either way. What changes is everything behind them.
| Aspect | Local-only | Cloud-backed |
|---|---|---|
| Where data lives | A database on the phone | A database on a server you own, cached on the phone |
| Login | None | Email, phone or social sign-in, password reset |
| First launch | Opens straight to the log | Sign-up or sign-in first |
| Backup | Device backup or a manual export file | Automatic, on the server |
| New phone | Restore from device backup or import the export | Sign in and the data is there |
| Second device or a partner | Not possible without export and import | Same account on any device; sharing if scoped |
| Offline | Always works | Works if offline caching and later sync are scoped |
| Account deletion | Delete the app | In-app account deletion and server-side data removal |
| Privacy disclosures | Short: data stays on the device | Longer: what is collected, stored and why |
| Running costs | Store accounts and maintenance | Plus hosting, database, auth and email services |
Both versions fit the kind of focused tool described on our custom utility app page. The cloud version simply carries a backend, an account system and the obligations that come with holding user data.
Backup is where local-only apps disappoint people
Local data survives app updates, but a lost phone, a factory reset or a careless uninstall can take it with them. Platform device backups help, though users do not always have them switched on, and restoring is all or nothing. If losing the data would be a real problem, plan one of these in version one.
- An export to a file (CSV or PDF) the user can save or email, which also covers the accountant use case
- An import that reads that same file back in, so a new phone can be restored
- Optional backup to the user's own cloud storage through the platform's file picker
- A full cloud account, if any of the reasons in the next section apply
What login adds to the build
Accounts are more than a sign-in screen. They bring sign-up, verification, password reset or passwordless codes, session handling, account deletion and, if you have staff, an admin view of users. Apple's App Review Guidelines (section 5.1.1) require apps that support account creation to offer account deletion inside the app, and a cloud app has to delete the server-side data too. Each of those is a flow to design and test, which is why accounts are listed as a separate price driver in every app quote.
Running costs after launch
| Cost | Local-only | Cloud-backed |
|---|---|---|
| Apple Developer Program | 99 USD a year | 99 USD a year |
| Google Play registration | 25 USD once | 25 USD once |
| Hosting and database | None | Monthly, grows with users and data |
| Auth and email delivery | None | Often free at low volume, then usage based |
| Monitoring and error tracking | Optional | Strongly advised |
| Maintenance | OS updates and fixes | OS updates, fixes and server upkeep |
Server costs for a small utility are often modest, but they never reach zero and they belong to you, because the hosting account is in your name. The maintenance guide covers what to budget each year.
Sources: [S19]: Apple Developer, Enrollment (opens in a new tab)[S20]: Google Play Console Help, Get started with Play Console (opens in a new tab)
How to choose
| If this is true | Lean towards |
|---|---|
| One person, one device, data is personal | Local-only with export |
| Data would be painful to lose | Local with backup, or cloud |
| The same person uses a phone and a tablet | Cloud |
| A manager needs to see staff entries | Cloud with roles |
| Data is sensitive and should not leave the device | Local-only |
| You want to email or message users later | Cloud with accounts |
Questions to answer before you ask for a quote
- Who needs to see each record: one person, a team, a manager, customers?
- How many devices does each person use?
- What would it cost you if a user's data disappeared with their phone?
- Is any of the data sensitive enough that it should never leave the device?
- Do you want to contact users or see usage across all of them later?
- Who will pay the hosting bill, and is that account in your name?
For field teams that need both offline work and a shared record, the offline field app brief goes deeper into sync. When you have decided, or want a second opinion, describe the workflow in the quote request and say which way you lean; the written scope will state the architecture it assumes.
Frequently asked questions
Is a local-only app cheaper to build?
Usually, because it skips the server, accounts and sync. It also has lower running costs, since there is no hosting bill.
Can a local-only app be upgraded to the cloud later?
Yes. It is easier if the brief mentions it, so the data is structured for sync from the start and existing users can move their data into a new account.
Does a local-only app still need a privacy policy?
Yes. The stores require privacy disclosures for every app, though a local-only app has less to disclose.
What happens to local data if the user gets a new phone?
It moves only through a device backup or an export and import feature, so plan one of those if the data matters.
Who pays for hosting on a cloud app?
You do, through a hosting account in your name, which also means the data and the account stay under your control.
Sources
- [S19] Apple Developer, Enrollment
- [S20] Google Play Console Help, Get started with Play Console
- Apple Developer, App Review Guidelines (5.1.1 Data Collection and Storage)
Written and reviewed by the DFY Games team. Published ; facts checked . Prices and store rules change: check the linked sources before you rely on a figure.