- Most mobile apps are only half the project: the back end handles accounts, data, notifications, payments and the admin side.
- Plan a versioned API from day one, because old app versions stay on people's phones long after you release updates.
- Push notifications go through Apple's and Google's services, usually with Firebase Cloud Messaging handling delivery across platforms.
- Apple requires apps that support account creation to offer account deletion in the app, and Google Play also requires a web link to request deletion.
- Budget for an admin panel, monitoring and hosting from the start; they are needed on launch day, not later.
What does a mobile app back end need besides the app?
Behind every useful mobile app sits a back end that handles user accounts and sign-in, a versioned API, the database, push notifications, file and image storage, payments, an admin panel, account deletion, analytics, monitoring and hosting. Many first quotes only cover the screens people see in the app. The back end is often half of the work, and leaving it out leads to surprise costs and a delayed launch.
This is the checklist our mobile app development team uses when scoping a new app.
How should accounts and sign-in work?
Decide early how people sign up: email and password, one-time codes, or sign in with Apple and Google. The back end issues and refreshes tokens, stores passwords safely, handles password resets and locks out repeated failed attempts. If your app offers third-party sign-in on iOS, check Apple's current App Review Guidelines for which login options must also be offered.
Why does the API need versions?
Unlike a website, you cannot update every copy of an app at once. People keep old versions for months. Version your API from the first release, keep older versions working for a while, and build a minimum version check into the app so it can ask users to update when an old version can no longer work. Choosing the back-end technology is a separate decision; our comparison of Laravel and Node.js helps there.
Where does the data live?
The back end owns the main database: users, content, orders, messages and settings. If the app must work without signal, plan local storage on the device and rules for syncing back, as explained in our guide to planning offline mode. Back up the database automatically and test restores.
How do push notifications work?
Notifications are sent through Apple's push service for iOS and Google's for Android. Most teams use Firebase Cloud Messaging, which Google describes as a cross-platform messaging solution, to deliver them to both. Your back end decides who should receive which message and when, stores each device's token, removes tokens that stop working, and respects each user's notification settings. Plan the types of notification in advance: transactional ones, such as order updates, and marketing ones, which need clear consent.
What about images and files?
Uploads such as profile photos and documents should go to object storage rather than your application server, served through a content delivery network for speed. The back end creates secure, time-limited upload links, resizes images, checks file types and sizes, and controls who can see which file.
How are payments handled?
Digital content and subscriptions sold inside apps usually have to use Apple's and Google's in-app purchase systems, while physical goods and many services can use a payment provider such as Stripe. The rules are detailed and change over time, so check the current App Store and Google Play guidelines for your business model. Either way, the back end verifies purchases with the store or provider before granting access.
Why do you need an admin panel?
From launch day, someone has to look up users, answer support requests, fix data, moderate content, send announcements and change settings. An admin panel with roles and an activity log makes this safe. Without one, every support request becomes a developer task.
Do apps have to support account deletion?
Yes, on both major stores. Apple's App Review Guidelines state that if an app supports account creation, it must also offer account deletion within the app. Google Play's account deletion requirements ask developers to provide an in-app path to delete accounts and associated data, plus a web link where users can request deletion. The back end must actually delete or anonymise the data, cancel related subscriptions where needed and record the request. Our guide to publishing on the App Store and Google Play covers the other store requirements.
What security does the back end need?
- Rate limiting on sign-in, password reset and other sensitive endpoints, to slow down automated attacks.
- Authorisation checks on every request, so users can only read and change their own data, even if someone calls the API directly.
- Secrets on the server only: API keys for payments, email and AI services never ship inside the app, because apps can be unpacked.
- Encrypted connections everywhere, and encrypted storage for sensitive data.
- Audit logs for admin actions such as refunds, data changes and account deletions.
How do you know the back end is healthy?
Add crash reporting in the app and error tracking on the server, so problems are seen before reviews mention them. Track API response times and error rates, set alerts for failures in notifications and payments, and watch hosting costs with billing alerts. Product analytics, with user consent where required, shows which features people actually use and where they drop off.
What is the full back-end checklist?
| Part | Needed at launch? |
|---|---|
| Accounts, sign-in, password reset | Yes |
| Versioned API with a minimum version check | Yes |
| Database with automatic backups | Yes |
| Push notifications and preferences | Usually |
| File and image storage | If users upload anything |
| Payments and purchase verification | If you charge |
| Admin panel with roles | Yes |
| Account deletion flow | Yes, if users create accounts |
| Analytics and crash reporting | Yes |
| Monitoring, rate limiting and alerts | Yes |
Should you build the back end or use a platform?
Backend-as-a-service platforms cover sign-in, storage and notifications quickly and suit many first versions. A custom back end suits complex rules, integrations with your existing systems or strict data requirements. Many apps combine both. Our custom software team builds the API and admin side, and our cloud and DevOps team sets up hosting, backups and monitoring, with automated deployments as described in our guide to CI/CD for small teams.
Frequently asked questions
Can we use Firebase or Supabase instead of building a back end?
For many apps, yes. Backend-as-a-service platforms provide authentication, databases, file storage and notifications out of the box, which speeds up a first version. Custom back-end code still makes sense for complex business rules, integrations with your own systems, or when you need full control over data and costs as you grow.
Who owns the app's data and servers?
You should. Hosting, databases, push notification credentials and app store accounts should be in your company's name, with the development team given access. That way you can change developers without losing your app, your users or your data.
Do we need a separate back end for iOS and Android?
No. One back end serves both platforms, and often a web app too. The apps talk to the same API, share the same accounts and data, and notifications are sent to each platform through its own push service. Building one well-designed API keeps behaviour consistent across devices.
How much does hosting a mobile app back end cost?
It depends on the number of users, how much data they store, how many notifications you send and the services you choose. Early apps can often run on modest infrastructure. Ask for an estimate based on your expected usage, and set billing alerts so costs never surprise you.
What happens to old app versions when the API changes?
Users keep old versions installed for months. Keep older API versions working for a period, and add a minimum supported version check so the app can ask users to update when an old version can no longer work safely. Plan this before the first release.
Is an admin panel really necessary at launch?
In almost every case, yes. Someone needs to look up users, fix data, handle support requests, moderate content and manage settings from day one. Without an admin panel, these tasks fall to developers running database queries by hand, which is slow, costly and risky.
Last updated