Most app budgets stop at launch. The build is quoted, approved and delivered, and then the first renewal notice arrives and nobody planned for it. An app differs from a website here in one important way: a neglected website keeps working, while a neglected app eventually stops being accepted by the stores or by the phones it runs on.
This covers what actually recurs. It is about apps specifically — our website maintenance guide covers the equivalent for a site, and the two have almost nothing in common.
The costs that arrive whether you touch the app or not
- Developer accounts. Apple charges an annual membership and Google a one-off registration. Miss the Apple renewal and your app is removed from the store until it is paid.
- Backend hosting. If the app has accounts, data, messaging or anything live, there is a server bill that grows with use.
- Push notifications, analytics and crash reporting. Free at small volumes, priced once you grow.
- Any paid SDK or API the app depends on — maps, payments, messaging, identity.
- Certificates and provisioning. Apple's signing certificates expire and must be renewed, or builds stop working.
The work that is not optional
This is the part that surprises people. Even with no new features, an app needs regular engineering time:
- New OS versions every year. iOS and Android both ship major releases annually, and things break — permissions change, layouts shift, APIs behave differently.
- Minimum SDK requirements. Both stores periodically require apps to be built against a recent SDK. Miss it and you cannot ship updates; eventually the listing can be hidden from new users.
- Deprecated libraries. A third-party SDK you depend on stops being supported, and replacing it is a development task with no visible benefit.
- New device sizes. A new phone with a different screen shape appears and your layout needs adjusting.
- Security patches in whatever the app depends on.
None of this produces a feature a user will notice. All of it is the difference between an app that still installs in three years and one that does not.
Store policy changes
Both stores change their rules, and compliance is not optional. Privacy disclosures, data-handling declarations, account deletion requirements, advertising identifiers and age ratings have all shifted in recent years, and each change meant existing apps had to be updated to stay listed.
Budget for a couple of compliance updates a year that deliver nothing to the user and are entirely unavoidable.
Support and reviews
An app has a public, permanent review page, and unlike a website nobody can quietly fix a bad first impression. Someone has to:
- Read and reply to reviews, including the unfair ones.
- Answer support messages from people who cannot sign in.
- Triage crash reports — a crash affecting one device model is invisible until someone looks.
- Watch whether an update made things worse, because a rating falls far faster than it recovers.
The costs that scale, and the ones that do not
It helps to separate the bill into the part that stays flat and the part that grows, because only one of them is a risk.
- Flat regardless of success: store accounts, signing certificates, the engineering retainer for OS and compliance work. These arrive whether ten people use the app or ten thousand.
- Grows with use: backend hosting, database, file storage, push notification volume, SMS or email, and any per-call API.
- Grows with failure: support time. A confusing release generates more messages than a year of normal operation.
The flat costs are the ones that catch small businesses, because they are due even in a quiet year when the app earned nothing. Know that number before you commission the build.
Two platforms means roughly two of everything
If the app ships on both iOS and Android, most of the maintenance happens twice — two OS release cycles, two sets of store policies, two review queues, two build pipelines and two sets of device sizes.
Cross-platform frameworks reduce the duplicated work but do not remove it, and they add a dependency of their own that has its own upgrade cycle. Whichever route you take, the honest question is whether you need both stores on day one, or whether one platform plus a mobile website would carry you further.
Plan for the quiet failure
Apps rarely break loudly. They stop working for a subset of users on a new OS version, and nobody tells you — they just uninstall. Three cheap habits catch it:
- Crash reporting that someone actually reads, with an alert when the crash rate moves rather than a dashboard nobody opens.
- A test install on a current device after every OS release, before your users do it for you.
- Watching the rating trend, not just the average. The average hides a bad month for a long time.
What a realistic yearly budget looks like
Rather than a figure that will be wrong for your app, budget by category and fill in your own numbers:
- Store accounts — fixed and small, but non-negotiable.
- Infrastructure — the bill that scales with your users.
- Third-party services — the ones you will forget until they invoice.
- Engineering retainer — the largest item, covering OS updates, SDK requirements and compliance. This is what most budgets omit entirely.
- Support time, in hours per week rather than money.
A reasonable rule: assume keeping an app alive costs a meaningful fraction of what it cost to build, every year, before you add a single feature. If that is not affordable, the honest question is whether you need an app at all — our app versus mobile website guide covers when a responsive site does the job for a fraction of the lifetime cost.
Questions to ask before you commission an app
- What will it cost to keep running for a year after launch?
- Who handles the annual OS updates, and is that included or billed?
- What happens when a store changes its policy — is compliance covered?
- Which third-party services does it depend on, and what do they cost at scale?
- Who holds the developer accounts, the signing certificates and the source code?
- What is the response time if the app breaks after an OS release?
That last set belongs in the agreement before work starts, alongside the ownership terms in a design contract. If you are still choosing who builds it, our guide to choosing a mobile app development company covers what else to ask.
We build and then maintain the apps we ship — see our mobile app development work, or contact us to talk through what your app would cost to keep running.
