The day your app gets approved in the store feels like the finish line. It’s actually the starting line. A website you can, in the worst case, leave running for a year without touching it and usually nothing happens. A mobile app, no. The system it runs on is moving underneath it constantly, and what works today will break a year from now. This lesson is about what to do with an app after it’s out, so it doesn’t quietly start dying on you.

An app isn’t done when you ship it, the ground keeps shifting under it

Both Apple and Google release a major version of their OS every year. On top of that come new devices, new screen sizes, new camera cutouts. You built your app for the world as it was on launch day. But that world keeps moving forward, with or without you.

A neglected app doesn’t go dark overnight. It withers instead. First the layout falls apart on a new phone, then Sign in with Apple stops working because a rule changed, and eventually the store stops listing it because you’re not targeting a recent enough OS version. The user, meanwhile, doesn’t see an “outdated library.” They see an app that doesn’t work.

A good rule of thumb: if you hand off an app to someone and nobody touches it for a year, assume that by the end of that year it won’t be in good shape anymore.

Crash reporting: you want to know about a problem before the reviews do

Without crash monitoring, you find out about a bug in one of three ways. Either an angry customer messages you, or you get a one-star review, or you don’t see it at all and users just quietly walk away. All three are expensive, and all three are avoidable.

A crash reporting tool (Sentry and Firebase Crashlytics are the common ones) sits right inside the app, and the moment something crashes it sends you a report: which phone, which OS version, which spot in the code. So you know about the bug before more people notice it.

Set it up at launch, not once things go wrong. Crash data you didn’t collect can’t be filled in after the fact. Same rule as analytics on a website.
Watch your crash-free rate. One number that tells you how the app is doing as a whole. A healthy app stays very high, comfortably above 99.5%.
Keep an eye on it after every update. A new version is the most common moment to break something. For the first few days after a release, check the numbers more often.

The analytics and metrics that actually matter: retention beats downloads

Download count is the most tempting and at the same time least useful metric you have. A download is a one-off gesture, often from an ad or sheer curiosity. It says nothing about whether anyone actually uses the app. You could easily have ten thousand downloads and three active users.

What to measure instead:

Activation. How many people get from downloading to that one action the app exists for (the first booking, the first message, the first workout). This is the first gate where most people drop off.
Day-one and day-thirty retention. Does the person come back the next day? And a month later? Retention is the most honest sign of whether an app is worth anything. You can buy downloads, you can’t buy retention.
Frequency of the core action. Not “time in app,” which often goes up precisely when the app is confusing and people are getting lost in it. Measure how often they do the thing they came for.

Steer clear of vanity metrics. Download count, number of screens, “time in app” all look nice in a slide deck, but they don’t pay the bills. Tie your measurement to the app’s single main goal, exactly as you defined it at the start, and ignore the rest.

OS and device updates: you have to keep shipping just to stand still

This is the thing that surprises people most. With a mobile app, you don’t ship updates only for new features. You ship them just to keep what you already have running.

The cycle is more or less dictated from above. New iOS and Android arrive in the fall, new devices in spring and summer. On top of that, Apple and Google regularly raise the minimum OS version and the toolkit (SDK) you have to build the app against, otherwise they won’t let a new update into the store. It’s not optional, and you don’t set the deadline.

In practice that means several smaller updates a year purely for maintenance, plus whatever you actually want to add or fix. Budget for it from the start. An app you’ve set aside money to build but not to run is an app that will stop working in two years.

What running it costs: an app is a commitment, not a one-off invoice

Let’s be straight about this, because it’s the most common nasty surprise. Building the app is the first payment, not the last. Several things go into running it:

Backend and hosting. If the app talks to a server (logins, data, notifications, as we covered in lesson five), that server runs somewhere and costs something every month. The bill grows with the number of users.
Store fees. An Apple Developer account is a yearly subscription, Google Play is a one-time entry fee. And if you sell digital content or subscriptions in the app, both stores take a cut of every transaction.
Maintenance. Those updates for new OS versions from the previous section. It’s not an optional luxury, it’s the rent you pay for the app to work at all.
User support. Someone has to answer questions and deal with reviews and the bugs people report. The more users, the more of this work there is.

So an app isn’t an expense you pay once and forget about. It’s an ongoing commitment, much like a car: the purchase price is just the start, the servicing and fuel keep running. If you know that up front, it’s perfectly fine to plan around. If you don’t, you hit the wall right at the moment you start having users.

You can take it on yourself, or hand it to us

This is where the whole handbook ends. We’ve gone from the question of whether you even need an app, through choosing the technology, the MVP, design, the backend, and launch, all the way here, to life after going live. Treat it as a map. If you want to take this on yourself, you’ve got enough in hand to make good decisions and not get taken for a ride.

And if you’d rather spend your time on your business, you can hand the whole thing to us. We build the app so that everything stays yours: the code, the Apple and Google accounts, the store listings, the domain. No locks you don’t hold the keys to. And because we know shipping isn’t the end, we talk with you about maintenance and running costs right at the start, not when the first OS update breaks something. Get in touch and let’s talk it through.