Contents6
An app does not only cost money on the day it is built. Once live, it runs on servers paid for every month, it must keep up with Apple’s and Google’s new rules, and its users ask for changes. Many quotes sum all this up as a yearly percentage of the development price. We prefer to split it into lines, because each has its own cause and rhythm.
In short
Three lines: running costs (monthly), imposed updates (several times a year), changes (as you choose).
Running costs start low and follow the number of users; a plan with no backups is not suitable for a business app.
Apple and Google raise their requirements every year: an app that is not updated eventually cannot ship a fix.
Small, frequent updates cost less than a big catch-up every two years.
The first line: keeping the app running
This is the most predictable part. It covers the server and database, hosting the web interface, sending email (sign-in codes, notifications) and the stores’ developer accounts.
For the database, take the example of Supabase, the back end Challenge Us runs on, a group-challenge app we built:
of inactivity is enough to pause a Free plan project, which includes no automatic backups
a month, the starting price of the Pro plan, with daily backups kept for seven days
in compute credits included each month in the Pro plan, enough for a small instance
A business app does not run on a plan that pauses and backs nothing up: budget for at least the paid tier. On the store side, Apple charges US$99 per membership year according to its enrolment page, and Google US$25 once according to the Play Console help. The choice of back end changes these lines: we compare the options in Supabase, Firebase or your own server.
The second line: updates you do not choose
This is the most often forgotten line. Apple, Google and the development tools move at their own pace, and an app must keep up to remain publishable.
- 29 April 2024
Apple requires apps uploaded to App Store Connect to be built with Xcode 15.
- 28 April 2026
Apple raises the minimum to Xcode 26 and the 26-generation SDKs (iOS 26, iPadOS 26).
- 31 August 2026
Google Play requires new apps and their updates to target Android 16 (API level 36).
- 1 November 2026
The latest extension Google allows developers to request for this requirement.
These dates come from Apple’s upcoming requirements page and Google’s target API level page. Google also spells out what happens to apps that do not keep up: an existing app targeting Android 14 or lower stays visible to new users only on phones whose Android version is no higher than its own.
Libraries follow the same movement. Expo, the tool we use to build a single app for the web, iPhone and Android, releases three new SDK versions each year. Following them one by one is regular, predictable work; skipping several turns the next update into a project.
Watch out
The app nobody touches any more
An app that works does not need new features, but it does need these updates. Without them, the day an urgent fix must ship, you first have to catch up one or two years of tooling.
The third line: changes
This is the only line you fully control. The first users ask for changes, the business creates others. This budget is set by the pace you want, and it can be zero in some quarters.
It benefits from being split into small releases. For Challenge Us, every change is checked automatically and previewed online before release, with a release log readable inside the app.
From the field
108 versions in five weeks for Challenge Us
Between version 1.0 on 2 September 2026 and 1.58.3 on 6 October 2026, Challenge Us went through 108 versions. That pace is only possible because each version is small, checked by automated tests and releasable without waiting for a store review, since its web version is served directly.
It is not a pace to copy: it is that of a young app. But the principle holds for all: many small checked releases cost less and break less than a few big ones.
The forgotten line: monitoring
A live app should warn you before its users do. At Palmora Property, a real-estate agency we work with, operations produce a report every morning (including the age of the backup), a restore test every month, and an alert if a task has not reported in for 30 hours; details are in the Palmora case study. A backup that has never been restored protects nothing, as shown in our article on what really breaks in server backups.
How to set the maintenance budget
- List running costs line by line.
Database, hosting, email, store accounts, with an order of magnitude for your number of users.
- Set aside the imposed updates.
A regular allowance to keep up with Apple, Google and libraries, separate from changes.
- Set a pace for changes.
Monthly, quarterly or on demand, depending on usage and your priorities.
- Write down who does what.
Who monitors, how quickly an outage is handled, who holds the access.
This breakdown follows on from what drives the development price of an app. An installable web app reduces part of the “stores” line, since its fixes do not go through a review: one of the arguments in our PWA or native app comparison.
Our app development delivers regular updates, a release log and the documentation to run the app, and scoping prices the running cost for your usage.
Frequently asked questions
How much does app maintenance cost per year?
There is no percentage that fits every app. Add up three lines: running costs (database, hosting, email, store accounts), which depend on the number of users; an allowance for updates imposed by Apple, Google and libraries; and the budget for changes that you choose. The first two cannot be cut; the third is up to you.
What happens if an app is never updated?
It may keep working for a while, but it degrades on two fronts. On Google Play, an app that does not target a recent API level is no longer offered to new users of recent phones. At Apple, shipping a fix requires rebuilding the app with recent tools. The day an urgent fix is needed, you first have to catch up.
Is maintenance cheaper for an installable web app?
Partly. Its fixes reach users as soon as they go live, with no store review, and it does not depend on Apple’s and Google’s yearly requirements to be published. It does, however, have the same running costs (database, hosting, email) and the same library updates as a native app.
Can we take maintenance of our app in-house?
Yes, if the code, the database, the store accounts and the hosting access are in your name, and if the app is documented. Check this in the development contract. You will also need someone who knows the tools used, or the time to train them, to keep up with the imposed updates.
Sources
- Apple Developer Program enrolment page (new tab)developer.apple.com
- Play Console help, registration fee (new tab)support.google.com
- Apple Developer, upcoming requirements (new tab)developer.apple.com
- Android Developers, target API level requirements (new tab)developer.android.com
- Expo documentation, SDK versions (new tab)docs.expo.dev
Jim · founder of Brain Plus AI
Also in web and mobile apps
Choose and price6 min
How much an app costs: what makes the price vary
A price range says nothing about your project: what makes an app quote vary is a handful of specific decisions, plus a monthly running cost to be priced separately. Here they are.
Choose and price6 min
App back end: Supabase, Firebase or your own server
Behind an app’s screens you need accounts, a database, files and rules. Supabase, Firebase and your own server answer this in three ways, and each commits you to different things.
Choose and price6 min
PWA or native app: which to choose for your business?
An installable web app (PWA) goes onto the home screen without going through the App Store or Google Play, and is enough in many cases, not all. Here is how to decide, and why we start with it.