How much does an app cost to maintain? The store fees come to 99 dollars a year, and the rest is hours and server bills.
Here is the position before the caveats. An iPhone app with no accounts and no server costs 99 USD a year to keep on the App Store, and an Android app costs nothing at all after a one time 25 USD signup. On a small app those are the only ongoing app costs that exist. Everything else in a maintenance budget is hours of work or server usage you have not had yet, and neither has a number until you supply one. The figure you will meet most often, that app maintenance runs 15 to 20 percent of the build price a year, is a price for somebody's labour rather than a cost your app generates.
So the useful answer is three columns, not one number: fees anyone can look up, variable costs nobody can quote honestly, and hours. This page fills in all three, says what the stores force you to do whether or not anything is broken, and then answers whether a monthly retainer is worth paying for. For one of the two readers here, it is not.
Split your own year into knowable and notThe short version
Fixed costs are knowable, variable costs are a usage question.
Split the budget in two before anyone argues about the total. On one side are the fees that arrive whether or not a single person opens the app: the Apple membership, a domain, any tool you pay for monthly. Write those down today and you will be right. On the other side are the costs that move with use: servers, bandwidth, storage, email, third party calls. Those have no number before you have users, and anyone who hands you one is guessing with your money.
The third line is left out most often and it is usually the biggest. Time. An app nobody changes still needs a release most years, because the platforms underneath it move on a schedule you do not set. Do that work yourself and it is free but not optional. Pay somebody and it is the whole bill.
The costs you can name today
Two fees set the floor. Apple's enrollment page puts the Apple Developer Program annual fee at 99 USD, with the Enterprise Program at 299 USD, charged in local currency where available and varying by region. It renews every year for as long as you want the app on the App Store. Accredited educational institutions can enroll with a fee waiver, which is worth checking if you are at one.
Google's side is not recurring, which catches out anyone who budgets both the same way. Play Console Help says registration is a one time 25 USD fee paid by card, with no annual renewal after it. So an Android only app that keeps its data on the phone has a store fee of zero in year two and every year after, while an iOS app has 99 USD a year forever. If you want the yearly cost of an app near nothing, that asymmetry is the largest lever you have.
The rest of the fixed column is whatever you chose: a domain, a crash reporting plan, the subscription for whatever you build with. Put them in one list with renewal dates next to them. Budgets drift not because a line grew but because nobody cancelled the four that stopped being used. Keep that list separate from your app development cost, which is a one off number answering a different question.
The costs nobody can quote you, us included
Now the honest half. Nobody can tell you what your server will cost, because the bill is a function of how many people use the app and what they do inside it. The number is not being withheld. It does not exist yet. What can be named in advance is its shape.
So start by asking whether you need a server at all. Plenty of apps do not. A tracker, a list, a timer, a journal: each can keep its data on the phone, and an app with no backend has a variable cost of exactly zero. Accounts, shared data, syncing between devices and payments are what force a server into the picture. If your app does not need those this year, the cheapest maintenance decision available is not to build one yet.
When you do have a server, four things move the bill and the rest is rounding: how much data you keep per user, how much of it is images or video, how often the app talks to the server, and whether anything runs on a schedule. Watch those four and next month is predictable from this one. Month twelve is not, because the line is not straight, and how cost as usage grows is a separate question with its own answer.
One more line hides well. Anything called per action carries a price per action: a map request, an AI completion, a text message, a verification email. Read the vendor's own pricing page before that feature ships, and set a spend cap while you are in there.
Try it
One year of upkeep, split into knowable and not
Fees and hours can be added up today. The server line stays blank on purpose.
99 USD a year you can name
Includes the 99 USD Apple Developer Program annual fee, which renews yearly. You valued the hours at zero, so they are missing from the total but not from the year. No server, so the variable column really is zero. The cheapest app to keep alive.
The work the stores make you do anyway
This is why a finished app is never finished. Google Play publishes target API level requirements with dates in them. Its requirements page says that since 31 August 2026 new apps and app updates must target Android 16, API level 36, to be submitted at all, and that existing apps must target Android 15, API level 35, to stay available to new users on devices running a newer version of Android than the app targets. An extension to 1 November 2026 can be requested. Miss it and the app does not disappear. It quietly stops reaching new phones, which is worse, because nobody notices.
Apple runs the same annual clock, with a new version of iOS each autumn and a queue of deprecations behind it. We read Apple's enrollment and renewal pages today and they cover fees, not build requirements, so this page does not print a minimum SDK version we could not verify. Treat the rule as one planned release a year to stay submittable, and look up Apple's current requirement when you schedule it.
Under your own code the same thing happens more slowly. Dependencies ship releases, and the gap between your versions and the current ones is a debt that accrues in silence. One upgrade a year is an afternoon. Three years of skipped upgrades is a project with a freeze in it. The same goes for app performance, because a new OS version can regress a screen that was fine last year. So budget one or two planned releases a year with an empty feature list. A skipped year is a deferred payment, not a saving.
So is a monthly maintenance retainer worth it
Usually no, at least not in year one, and not for an app that keeps its data on the phone and earns nothing yet. A retainer buys availability. If the honest list of work for the next six months is one release to keep up with the stores, you are paying twelve months of availability for two days of work, and you can buy those two days when the deadline arrives.
Three things change the answer. Money moves through the app, so a day of downtime costs more than a month of retainer. Somebody else wrote it and you cannot read the code. Or there is a server, which can fail at three in the morning in a way an app on a phone cannot. In those cases you are buying a response time, not a number of hours, so price it that way.
Which reader you are decides the whole figure. If you own the code and do the work, your app upkeep budget is two store fees, a server bill you can watch, and hours you are free to value at zero, as most solo builders quietly do. If you pay for every change, you are buying hours at somebody's rate, and the 15 to 20 percent rule becomes roughly true, because it always described a rate card rather than your app.
Either way, hold the accounts yourself. The Apple membership, the Play Console account, the domain and the hosting belong in your name on your card, with the contractor invited in. The worst maintenance problem is not a bill. It is an app nobody can update because the store account belongs to somebody who stopped answering email.
What a year of upkeep actually contains
| What you are keeping alive | Store fees a year | Server bill | Releases the stores force | Cost of skipping them |
|---|---|---|---|---|
| iOS only, data on the phone | 99 USD | none | about one | small, it keeps working |
| Android only, data on the phone | nothing after the 25 USD signup | none | one, at the API level deadline | new users stop seeing it |
| Both stores, accounts and syncing | 99 USD | depends on usage | one or two | outage, then churn |
| Both stores, payments and paid APIs | 99 USD plus vendor fees | usage plus a price per call | one or two, plus vendor deadlines | revenue stops |
| Built and run for you by an agency | billed through to you | billed through to you | whatever the retainer covers | you pay in months, not in work |
Building an app that is cheap to keep alive
The cheapest app to maintain has the fewest moving parts, and most of those parts get added in week one out of habit. An account system nobody asked for, a server holding data only one phone reads, a payments SDK in a free app: each adds a bill, a vendor deadline and something that can be down. Adding them later is easy. Removing them later is not.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month with no free plan, so treat that as a line in your fixed column for as long as you are still changing the app. New apps start local first: data stays on the phone, with no accounts and no server. Newly Backend is added only when the app needs accounts, shared data, syncing or payments, and then brings sign in, an API service, a Postgres database per environment and file storage. That order suits a maintenance bill, because the server arrives when something needs it rather than on day one.
Because the code is yours, the subscription and the app are separable. Take the project out as a ZIP from Settings, or through the two way GitHub sync under Deploy, and what is already live stays live. Decide one thing before you start: which of the three columns you will carry for three years. Fees are easy. Hours are the column people overestimate their appetite for. A server is a promise to be reachable.
Questions people ask about ongoing app costs
For an app with no server that you maintain yourself: 99 USD a year for iOS, nothing recurring for Android after the one time 25 USD signup, plus your own hours. Add a server and the bill becomes whatever your usage costs. Pay somebody else to do the work and the hours become the largest line by far. When you are quoted a single number, ask which of those three it is describing.
Write the three columns before you build
List the fees with their renewal dates, mark the server line unknown until you have users, and put a real number on the hours you will spend each month. That list is a maintenance budget. One figure is a guess.
Start building