The app is approved, the listing is live, and the first reviews are kind. Six months later a customer emails to say it crashes when they open it. Nobody on your side changed a thing. That is exactly the problem: the phones changed, the stores changed, and the app stayed where it was.

A website can sit untouched for a year and mostly keep working. An app cannot. It lives on devices and in stores that someone else controls, and both move on a schedule that does not wait for you. Here is what keeping one alive actually involves, so you can budget for it before launch instead of discovering it after.

The phones keep changing

Apple and Google each ship a major operating system update every year, plus smaller ones in between. Each can change how permissions work, how notifications behave, how the screen is laid out, or retire something your app relied on. New phones arrive with new screen shapes and sizes. Most of the time an app keeps running. Sometimes a button slips under the camera notch, a login screen stops accepting taps, or location quietly stops working because the permission rules moved.

The fix is unglamorous: test the app on the new versions as soon as they are available in beta, not after customers find the problem. Keep a small set of real devices, old and new, and run through the main paths on each one before every release.

The stores keep changing their rules

Both stores raise their technical minimums on a regular cycle. Google Play requires apps to target a recent version of Android to keep publishing updates, and Apple requires apps to be built with recent versions of its tools. An app that falls far enough behind cannot ship an update at all, which means the day you need an urgent fix, you first need a modernization project.

The stores also review policy as well as code. Privacy disclosures, account deletion, payments, and what you say in the listing all have rules, and the rules get revised. Your privacy answers in the store have to match what the app actually collects, including anything a third-party tool inside it collects. Someone should read the stores’ policy updates as they come out and check the app against them.

The parts inside it age

Very little of a modern app is written from scratch. It uses libraries for payments, maps, analytics, sign-in and notifications, and those come from other companies on their own timelines. A library gets a security fix, changes how it works, or is retired outright. Certificates and keys that let the app send push notifications or talk to your servers can expire.

Behind the app there is usually a server, a database and a set of connections to your other systems. Those need the same care a website does: updates, backups and someone watching them. If the app talks to your booking system, your point of sale or your customer records, a change on that side can break the app without anyone touching the app itself.

Know when it breaks, before your customers say so

Crash reporting is the single most useful thing an app owner can have. It tells you which screen failed, on which device and which version, often before a single review mentions it. Pair it with simple analytics on the paths that matter, such as sign-up, booking or checkout, so you notice when a step suddenly stops working.

Then read the reviews. Store reviews are where people tell you what confused them, and a reply to a one-star review is read by everyone deciding whether to install. Our piece on what to do when you get a bad review applies to app stores just as much as Google.

The costs owners forget

Plan for these every year, not just at launch:

Developer accounts. Apple’s program renews annually, and the app comes down if it lapses.
Hosting and services. Servers, databases and the third-party tools inside the app often bill monthly and grow with use.
Operating system updates. A round of testing and fixes every time Apple and Google ship a major release.
Store compliance. Time to update the build tools, the privacy answers and the listing when the rules change.
Improvements. The features customers ask for, and the fixes to whatever the analytics show people struggling with.

None of these is a reason not to build. They are the difference between an app that is still earning its place on someone’s phone in year three and one that was quietly abandoned in year one. If you are still deciding whether to build at all, should your business have its own app walks through that choice, and a good app brief should ask for an aftercare plan alongside the build price.

Questions to ask about your app today

When was it last updated in the stores, and who did it?
Has anyone tested it on the newest iPhone and Android versions?
Do you get crash reports, and who reads them?
Are your store privacy answers still true?
Who renews the developer accounts, and when?

If most of the answers are “not sure,” the app is running on borrowed time. It usually keeps working until the update that it does not survive.

What we do

We design, build and launch iPhone and Android apps in house, and we support them after launch: monitoring, updates and fixes, store submissions, analytics, and the ratings and reviews that follow. We run our own apps the same way, which is why we treat launch as the start of the work rather than the end. Read more on our mobile application development page.

If you have an app that nobody has looked at in a while, or one you are about to build, talk to us before the next operating system update does the talking for you.