Do You Need a Backend, and Do You Need Accounts?

These are two separate questions with two separate answers, and merging them is how teams end up building a login screen they were never allowed to show and a purchase flow they cannot audit. Accounts are a policy question first. A backend is an architecture question that the stores answer for you the moment you take money.

The pattern is consistent. Somebody decides the app needs users, so it needs sign-up, so it needs a database, so it needs an API, and four weeks disappear before a screen does anything a user asked for. Then review rejects the login gate.

Split it properly:

You can need a backend and not need accounts, and that combination is usually the right first release. Across the 300+ apps we have managed since 2013, the expensive mistake here is not choosing wrong — it is answering both questions with one shrug and building for the harder case before anyone has downloaded anything.

Not unless the app has significant account-based features — Apple's wording is that if your app doesn't include significant account-based features, you must let people use it without a login. That is a requirement, not advice, and it is one of the more commonly hit walls in review.

Guideline 5.1.1(v) in the App Review Guidelines is short and unusually plain. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law. If your core functionality is not related to a specific social network, you must provide access without a login or via another mechanism.

Apple also closes the obvious loophole in the same paragraph: pulling basic profile information, sharing to the social network, or inviting friends to use the app are not considered core app functionality. A sign-in that exists so you can send push notifications and count users is exactly the case the guideline is written against.

There is a second cost that has nothing to do with review. A registration wall in front of the first useful moment is measured in installs that never become users. Our guide to onboarding that survives first launch covers where the account request belongs when you genuinely need one — later, after the app has proved something.

Note what the guideline does not say. It does not prohibit accounts. It prohibits requiring them before the app functions. Offering sign-in, and letting a user skip it, satisfies the rule and preserves the option.

Deletion, on both stores, and Google Play requires two separate paths rather than one. This is the obligation teams discover after shipping, usually as a policy warning rather than a design decision.

Apple's rule sits in the same guideline as the login rule: if your app supports account creation, you must also offer account deletion within the app. The supporting documentation is specific about what counts. You must offer to delete the entire account record, along with associated personal data. You may include additional options, but only offering to temporarily deactivate or disable an account is insufficient. If people need to visit a website to finish deleting their account, include a link directly to the page on your website where they can complete the process. And Apple answers the workaround question directly — an app that links out to a web browser for account creation still needs to offer account deletion within the app.

Google Play's requirement is stricter in shape. Its page on app account deletion requirements states that developers whose apps enable account creation must provide users with an in-app path to delete their app accounts and associated data, and provide a web link resource where users can request app account deletion and associated data deletion. Both, not either. The web resource must be functional, relevant in scope with deletion prominently featured, and reference the app or developer name as it appears on the store listing, and users must be able to submit a deletion request without being required to reinstall the app.

That last clause catches teams who built deletion as a screen buried inside a signed-in settings menu. A user who has uninstalled has no in-app path, which is why the web resource is required alongside it.

There is a monetisation wrinkle attached. Apple's guidance is that if the user has auto-renewable subscriptions, you should notify them that their billing will continue through Apple and request that they cancel the subscription before continuing. Deleting the account does not cancel the subscription, and a user who discovers that on their next statement writes the review you spend a quarter recovering from.

Yes — using a third-party or social login service as the primary account obliges you to offer an equivalent alternative with three specific properties, unless you fall into one of the listed exceptions. This is guideline 4.8, and it is why a "just add Google Sign-In, it is one afternoon" plan rarely stays one afternoon.

Apple's wording is that apps using a third-party or social login service to set up or authenticate the user's primary account must also offer as an equivalent option another login service where the service limits data collection to the user's name and email address, allows users to keep their email address private as part of setting up their account, and does not collect interactions with your app for advertising purposes without consent.

Apple then lists cases where another login service is not required. The exceptions matter as much as the rule:

• Your app exclusively uses your company's own account setup and sign-in systems. Note the word exclusively: the exemption applies where your own system is the only sign-in option, not merely where you also offer one alongside third-party logins.
• Education, enterprise or business apps that require the user to sign in with an existing education or enterprise account.
• Government or industry-backed citizen identification systems or electronic ID used to authenticate users.
• Clients for a specific third-party service where users must sign in to their mail, social media or other third-party account directly to access their content.
• Alternative app marketplaces, and apps distributed from one, using a marketplace-specific login.

Read that list as a decision aid, not a set of loopholes. The exemption is for apps that use your own account system exclusively, so adding a third-party social login alongside it takes you outside that exemption rather than leaving you inside it. It appears when a social provider is the only way to establish a primary account.

The 5.1.1(v) point still applies underneath all of this. A third-party login is still a login, and a login you were not entitled to require does not become permissible because you offered two of them.

On Google Play, not properly — Google's own launch documentation says you should create a secure backend server to receive real-time developer notifications, and that those notifications do not give you complete information about the purchase. This is the clearest "you need a backend" statement either store publishes, and it is worth reading in full before you plan a client-only implementation.

Google's Play Billing getting-ready guide describes real-time developer notifications as a mechanism to receive notifications from Google whenever there is a change in a user's entitlement within your app, delivered through Cloud Pub/Sub. It states that to receive them you should create a secure backend server to consume the messages sent to your Cloud Pub/Sub topic. And then the note that decides the architecture:

Take that literally. The notification is a signal that something happened, not a record of what happened. A design that treats the payload as the source of truth for entitlement is building on a document that says it is not one. Google is explicit that the Play Developer API is a server-to-server API providing functionality not available in the Play Billing Library, such as securely verifying purchases and issuing refunds, and that you must configure access to it through Play Console as part of integrating billing.

There is a hard deadline in the same area that a client-only implementation handles badly. Google's billing documentation states that after granting entitlement your app must notify Google that the purchase was successfully processed, and that this must be done within three days so that the purchase isn't automatically refunded and entitlement revoked. Google recommends the server-side acknowledgement endpoints where you have a secure backend, and notes that while you can acknowledge or consume on the client, server-side APIs provide additional protection against issues like poor network connectivity and malicious activity.

A user who pays, then loses connectivity or force-quits before the client acknowledges, is a user who gets automatically refunded three days later while your app still believes they are subscribed. That failure mode is silent, it is entirely on the client path, and it is why acknowledgement belongs on a server. Teams migrating their billing stack should read this alongside our notes on the Play Billing Library 8 migration.

If subscriptions are your revenue, the thing that decides who has paid should not live on a device you do not control — which is also the case for a managed layer rather than a bespoke one, as we compare in StoreKit versus RevenueCat.

Replay and tampering, and Google documents the specific defence — record every purchase token, check the current one against every previous one, and confirm it with the Play Developer API. Google's guidance on this is prescriptive enough to implement directly.

Its fraud and abuse guidance names purchase verification and acknowledgement as a special case of sensitive data and logic that should be handled in the backend. After a user makes a purchase, Google says you should send the corresponding purchase token to your backend, meaning you maintain a record of all purchase token values for all purchases; verify that the token for the current purchase does not match any previous token value, noting that the token is globally unique and can safely be used as a primary key in your database; and use the Play Developer API endpoints for products or subscriptions to verify with Google that the purchase is legitimate.

The general principle Google states around it: as much as your app design permits, move sensitive data and logic to a backend server that you control, because the more data and logic you have in a frontend device, the more vulnerable it is to being modified or tampered with.

Three consequences follow, and they are all architectural rather than cosmetic:

Point two settles this article's central question. Needing a backend for billing does not mean needing accounts: an anonymous identifier satisfies entitlement without a sign-up screen. That is the shape Firebase Authentication documents for anonymous accounts, which let users who have not signed up work with data protected by security rules, and can later be upgraded to a regular account so the user continues where they left off.

More than most teams assume, provided the app is not selling anything and not sharing state between people. The honest boundary is not "simple apps versus complex apps" — it is whether anything in the product needs to be true for someone other than the person holding the phone.

A tool that computes, records, edits or organises on-device data needs no server at all. Neither does one whose only remote dependency is a public API it reads from. On Apple platforms, cross-device continuity is available without operating infrastructure: CloudKit stores your app's data in iCloud and keeps it up to date across devices and on the web, storing private data in users' own iCloud accounts, with encryption configurable on fields in private databases. That is device sync and a user identity without you running an authentication system or a login screen — and, notably, without triggering the account-creation obligations from the previous sections, because the user is not creating an account with you.

The line moves the moment one of these is true:

• You take money in-app. Covered above; the store documentation settles it.
• Two users need to see the same thing. Messaging, sharing, leaderboards, teams. Someone has to hold the shared state.
• You must change behaviour without shipping a build. Remote configuration, feature flags, content that is not tied to a release.
• Something must be authoritative against a determined user. Entitlements, quotas, credits, anything with a price attached.
• You need a cross-platform identity. A user on iOS today and Android next year is a server-side identity problem, not a client one.

What is not on that list is analytics. You do not need a backend to understand your funnel — an analytics SDK covers it, and confusing the two is how teams justify infrastructure they will not maintain. We set out the alternative in our guide to funnel analytics for apps.

The pattern we see repeatedly in our portfolio is a first release that needs exactly one server-side capability — usually billing — and a team that builds a full identity platform to get it.

When losing them costs the user something they would miss — restoring purchases on a new device, keeping work that took effort to create, or being reachable by another person. Everything else is instrumentation dressed up as a feature.

Run the question from the user's side. What does an account give them? If the list is empty, 5.1.1(v) is not an obstacle to work around; it is a correct reading of your product. If the list is real, the account is something users will ask for, and the conversion cost of the sign-up screen drops because there is a reason attached to it.

The sequencing that works is anonymous-first with a documented upgrade path. Firebase Authentication describes exactly this: temporary anonymous accounts let people use features that require authentication without signing in first, and if the user later chooses to sign up you can upgrade the anonymous account to a regular account, so the user can continue where they left off. The app functions immediately, the entitlement has something to attach to, and the account appears at the moment it becomes useful rather than at first launch.

Two operational points. A purchase made anonymously still has to be restorable, so your entitlement record needs a route to the new account at upgrade — design that before you ship. And the moment you allow the upgrade you have enabled account creation, so every deletion obligation above applies from that release onward.

For subscription products specifically, the account question is entangled with the payment question in markets where the mandate lives outside the store — we cover one such case in our piece on UPI AutoPay and app subscriptions.

Decide the two questions independently, ship the smallest server that the store rules actually require, and keep identity anonymous until a user benefit forces it. The rewrite risk sits almost entirely in identity, so that is the decision to defer and the one to design for.

One thing we deliberately do not publish here is a cost or a timeline for any of this. We have no defensible figure for what a billing backend costs to build in a given stack, and inventing one to look authoritative would be worse than useless to anyone budgeting against it. What is defensible is the scope, and the scope above is drawn entirely from the stores' own documentation.

This decision deserves care because it front-loads the whole schedule. A team that answers "yes" to both by default spends its first month on infrastructure and its second on a rejection, before anyone has learned whether the product works. Our guide to publishing a first app covers what that month buys you spent on the listing instead, and the common rejection reasons covers what else review looks for.

If you are staring at a login screen you are not sure you are allowed to ship, or a subscription flow with no server behind it, that is usually a short conversation for someone who has seen both go wrong — tell us what the app does without an account, or see how we approach the paid side in our monetisation work.