What It Costs to Keep a Mobile App Running After Launch

A website can sit still for years and carry on working. A mobile app cannot, because it lives inside two operating systems that change every year and two stores whose rules change more often than that. Standing still is not an option that is available to you.

So the honest way to budget an app is as a running commitment with a build at the front of it. If you cannot fund the running, do not fund the build. An app that is launched and then unfunded does not stay as it was. It decays quietly for about a year and then breaks all at once, usually on the morning somebody important tries to show it to somebody else.

What follows is every category of cost that arrives after launch, roughly in the order businesses meet them. None of it is exotic. All of it surprises people, because the conversation before a build is about features and the conversation after it is about maintenance, and those two conversations often involve different people.

Both stores require a developer account. Apple's renews every year. Google's is a one off registration. These are the smallest bills on the list and also the ones that expire quietly and take your app out of the store while everybody assumes somebody else is handling it.

Whose account it is matters more than what it costs. Register in the company's name, pay on a company card, and make sure more than one person can get in. An app sitting in a former employee's personal developer account is a genuine emergency with no clean fix, and it happens often enough that it is worth checking yours today.

Business accounts also need verification. Both stores want to confirm your company is real, which means legal entity details, an address, and in Apple's case a business identifier you may have to apply for. Verification can be run again later, and it takes as long as it takes. Leave it to the week of a deadline and you will discover how little control you have over that timing.

Then there are the keys. Apple's distribution certificates and profiles expire and have to be renewed, which is a small task that stops releases dead when nobody has done it. Android's app signing key is more serious: it identifies your app forever, and if you lose it and are not enrolled in a managed signing scheme, you cannot publish an update to your own app. Store it the way you would store a company seal.

Every year both platforms ship a major release, and every year some things behave differently. Some of it is cosmetic, some of it is a permission that now behaves more strictly, and occasionally something you relied on is simply gone.

Both stores also require apps to be built against a reasonably recent version of the platform tools, and they set a date each year. Miss it and you cannot publish an update at all. Keep missing it and the app eventually stops being offered to new devices. So even an app with no new features needs a rebuild, a test pass on the new operating systems and current devices, and a release, roughly once a year, purely to stay where it is.

Devices add their own work. New screen shapes, new aspect ratios, folding screens, changes to where the system puts its own controls. Layouts that were correct become slightly wrong, and slightly wrong on the checkout screen is a support ticket.

Plan for this deliberately as an annual slot in the budget rather than as an interruption. Teams that schedule it do it calmly in a quiet month. Teams that do not do it in a panic, in the same week as something urgent, which is when mistakes get shipped.

Behind almost every app there is a server, a database, file storage, a notification service and somewhere for images to live. That bill arrives monthly and it grows with use, which is a good problem and still a problem.

The costs that surprise people are rarely the obvious ones. Data transfer out is one. Storage that only ever grows, because nothing in the system deletes anything and nobody wrote a retention rule. Logging, which is cheap per line and expensive per year. And backups, which are quietly proportional to everything else.

Managed services are worth their price and they are not fixed. Vendors change pricing, free tiers end, and a product you built on gets folded into something more expensive. Anything you depend on is a commercial risk as well as a technical one.

And somebody has to patch it. The server behind an app has exactly the same security update needs as any other server, plus the same monitoring and the same requirement that somebody notices when it stops. Budget for that person, or buy it as a service, but do not assume it happens by itself because the app is finished.

Most apps lean on a handful of outside services. Maps. Text messages for verification codes. Email delivery. Payments. Analytics. Crash reporting. Sign in providers. Sometimes a chat widget or a support tool. Each has its own pricing, its own limits and its own idea of when to change.

The expensive failure is a deprecation. A vendor announces that the version of their library you use will stop working on a stated date. Now you have unplanned development work with a hard deadline set by somebody who does not know or care about your roadmap. This happens to every app that lives long enough.

Keep a list. Every outside service the app depends on, what it costs, when it renews, which version of their library you are on, and how long that version is supported. It takes an afternoon to write, it needs updating once a quarter, and it is the cheapest item in this entire article. Almost nobody has one.

Store reviews are public and they need answering. So do the emails. Somebody in your business owns that job, and if nobody has been given it, the answer is that nobody does it and the rating slides.

The messages arrive in a predictable set of shapes. I cannot log in. You charged me twice. My data has gone. It crashes when I open this one screen. Please add this feature. And, if the app has any public content at all, somebody reporting somebody else. That last category needs a process before you need it, not after.

To answer any of these you need to be able to see what happened, which means crash reporting and enough logging to reconstruct one user's afternoon. Without that, every support conversation ends with asking the customer to try again, which is not support.

One bad release will teach you the value of staged rollouts. An update that crashes on launch on a common device produces a wave of one star reviews within hours, and the average rating carries that weight for months after the fix has shipped. Releasing to a small share of users first, watching the crash rate, and only then going wider costs nothing and prevents exactly this.

This is the one that catches people completely off guard. Store rules change, and they are applied at your next submission, whatever that submission happens to contain. An app that passed review comfortably two years ago can be rejected on a routine bug fix because a policy arrived in between.

The recurring ones are worth knowing. A requirement to let users delete their account from inside the app. Privacy declarations that have to match what the app and its libraries actually collect. Justifications for permissions, particularly background location. Rules about which sign in options you must offer. Stricter requirements for anything aimed at children. Changes to what may be sold outside the store's own payment system.

The trap is the timing. You discover the new requirement while trying to ship an urgent fix, so a crash affecting every user sits in review while somebody argues about a privacy label. That is a bad week and it is entirely avoidable.

Avoid it by reading the policy emails when they arrive rather than filing them, and by doing a compliance pass on a release nobody is waiting for. Once a year, ship an update whose only purpose is to be current. It is the least interesting release you will ever plan and it will save you a genuinely awful week.

Split the running cost into five buckets and the conversation gets much easier. Fixed annual items: developer accounts, certificates, any licence. Usage based items: servers, storage, transfer, outside services. Scheduled work: the annual operating system pass and the compliance release. Unscheduled work: bugs, incidents, a vendor deprecating something. And product work, meaning the features you actually want.

The first four exist whether or not you ever add a feature. That is the number to say out loud before the build starts, because it is the number that decides whether the app is a good idea at all. An app is a subscription you are paying to yourself.

The caveat sales conversations skip is this. Plenty of businesses should not build an app, and the running cost is what tells them. If the running budget is not there for the following few years, the honest recommendation is a mobile website, and any developer who will not say that out loud is selling rather than advising.

Finally, name an owner. Not a team. A person, with a recurring slot in their month for the app, and the authority to spend a small amount without a meeting. Apps that have one of those stay healthy. Apps that do not become a rebuild in three years, and the rebuild costs more than every year of maintenance nobody funded.