Choosing a Backend for a Mobile App

What the backend does

The app on the phone is usually the smallest part of the system. Behind it sit the user accounts, the database, file storage for photos and documents, the logic that must not run on the phone (prices, permissions, payments), push notifications and the admin dashboard your team uses. Together these are the backend, and the app reaches them through an API. Our guide APIs and integrations, explained covers how APIs work in plain terms.

There are two common ways to build it:

• A managed backend (often called backend-as-a-service), where a provider runs the database, sign-in and storage and you configure them and add your own rules and functions.
• A custom API, written for your app and run on servers or cloud services you choose.

Many projects mix the two, for example managed sign-in with a custom API for the business logic.

Managed backends: Firebase and Supabase

Firebase is Google's app platform. Its documentation lists products including Authentication, Firestore and Realtime Database (NoSQL cloud databases), Cloud Storage for files, Cloud Functions to "run backend code in response to events without provisioning or managing a server", Cloud Messaging for notifications and Security Rules to "define granular, server-enforced rules to protect your database and storage data".

Supabase is built around a standard database. Its documentation describes "a Postgres database, authentication, instant APIs, edge functions, real-time subscriptions, and storage", and says "Postgres is the core of Supabase".

A managed backend suits an app whose needs are mostly accounts, storing and syncing data, files and notifications. It can get a first version, such as an MVP, in front of users with less server work. The trade-offs are that you work within the provider's model and pricing, and the security rules become critical code: in both products the rules (Firebase Security Rules, Postgres Row Level Security in Supabase) are what stop one user reading another user's data, so they need the same review and testing as any other code.

A custom API

A custom API makes sense when the app is one part of a larger business system: it has to talk to your existing database, CRM, ERP or stock system, apply complex business rules, or serve a website and an app from the same backend. Our guide Web app vs website explains when a project has become software rather than a site, and the same signs apply here.

The cost of a custom API is that someone has to run it: servers, security updates, monitoring and backups, for as long as the app is live. Ask whoever builds it who will do that and how, before you choose.

Sign-in and permissions

Sign-in is where a backend most often goes wrong, so it is worth using proven components rather than writing it from scratch.

• Firebase Authentication "provides backend services, easy-to-use SDKs, and ready-made UI libraries" and supports "passwords, phone numbers, popular federated identity providers like Google, Facebook and Twitter, and more". Google says that upgrading to Firebase Authentication with Identity Platform adds features such as multi-factor authentication and user activity and audit logging.
• Supabase Auth supports passwords, magic links, one-time passwords, social sign-in and single sign-on, uses JSON Web Tokens, and stores its user data in your project's own Postgres database. It integrates with Row Level Security for deciding who can see what.

Whichever you use, the server must check who the user is and what they may do on every request. Our mobile app security guide explains why checks inside the app alone are not enough.

Where the data is stored

If your users are in the UK or EU, where their personal data is stored and processed matters. The European Commission explains that when personal data is transferred outside the European Economic Area, "special safeguards are foreseen to ensure that the protection travels with the data", such as adequacy decisions, standard contractual clauses and binding corporate rules. The UK GDPR has a similar regime of its own.

Both managed backends let you choose locations, but you have to choose them:

• Firebase's locations page says "There's not a global project-level or app-level setting for location". Locations are set per product or resource: Firestore, Realtime Database and Cloud Storage have no default and must be set, while Cloud Functions default to the us-central1 region if no location is set.
• Supabase's regions page says each project is deployed to one primary region, which "determines where your primary project data is stored". It warns that its general "Europe" region includes London and Zurich, "which are not EU member states", so choose a specific region if your data has to stay in a particular jurisdiction. It adds that "Region selection is a data-location control, not proof of regulatory compliance."

Location is only part of the picture. Firebase's privacy page says Google is "generally a data processor under GDPR" when customers use Firebase, lists its data processing terms and standard contractual clauses, and says Google is certified under the EU-U.S. Data Privacy Framework and its UK Extension. Your privacy policy and your app's store privacy labels should describe these services accurately.

Backups, exports and lock-in

Before you commit to a backend, check how you would get your data out, both for backups and in case you ever move.

• Firestore has a managed export and import service that writes data to a Cloud Storage bucket. Google notes that it needs the paid Blaze plan and that exporting "will incur one read operation per document exported". The export is in Firestore's own format, so moving to a different database is a migration project rather than a copy.
• Supabase uses standard Postgres, and its migration guide uses the standard Postgres tools pg_dump and restore. Its backups page says Pro projects can access the last 7 days of daily backups, Team projects 14 days and Enterprise projects up to 30 days, and recommends that free plan projects "regularly export their data" and keep off-site backups. It also says deleting a project permanently removes its data, "including any backups".

A custom API on a standard database is the easiest to move, but only if you have the code, the database and the server access. Make sure the accounts for every backend service are in your company's name, as our guide on what you should own explains.

Account deletion: what the stores expect

If your app lets people create an account, both stores require a way to delete it, and most of that work happens in the backend.

• Apple says apps that support account creation "must also let people initiate deletion of their account within the app", and that deleting an account removes it "along with any data associated with the account that the developer isn't legally required to maintain". Offering only to deactivate an account "is insufficient". Apps using Sign in with Apple should use Apple's REST API to revoke user tokens.
• Google Play requires an in-app path to delete the account and associated data and a web link where users can request deletion. If service providers process the data, Google says you "should delete the data from your own servers and request the service provider to do the same".

So the backend needs one deletion process that reaches the database, stored files, the sign-in provider and any other services holding the user's data. Plan it at the start; adding it later means finding every place data was copied.

A checklist

• List what the backend must do: accounts, data, files, notifications, admin, integrations with your other systems.
• Decide managed, custom or a mix, and who runs and updates it after launch.
• Use a proven sign-in service, and check permissions on the server for every request.
• Have the security rules or access policies reviewed and tested.
• Choose and record the location of every service that holds personal data.
• Confirm backups, how far back they go, and how you would export everything.
• Build account deletion end to end, including third-party services.
• Keep every backend account in your company's name.

Frequently asked questions

Is Firebase or Supabase better for a business app?

It depends on the data and the team. Firebase's main databases are NoSQL, while Supabase is built on Postgres, a standard relational database that can be dumped and restored with standard Postgres tools. Choose on the shape of your data, the regions you need, how you would export it, and what your developers know well.

Can we start on a managed backend and move later?

Yes, but plan for it. Keep your business logic in clearly separated code, make sure you can export all data, and remember that user accounts and passwords also have to move. Moving a NoSQL export into a different database is a migration project, not a copy.

Do we need servers if we use Firebase or Supabase?

Not for the parts they provide, such as the database, sign-in, storage and functions. You may still need a server or cloud functions for work that must not run on the phone, such as talking to your other business systems with secret keys.

What happens to user data when someone deletes their account?

Apple and Google both require apps that offer account creation to offer account deletion. Apple says the account and its associated data should be removed unless you are legally required to keep it, and Google says to delete data from your own servers and ask service providers to do the same.

Planning an app? We build the backend, API and admin dashboard together with the iPhone and Android app, so the whole system is planned from the start. See our mobile app development service and all our services, or email [email protected].