What Happens After Your App Launches: The First Year of Upkeep

Indore, 1 November 2026, I get asked some version of the same question near the end of almost every project: once the app is in the stores, are we done? The honest answer is that the build is done. The app is not. A mobile app sits on top of two operating systems, a pile of third-party packages, a server and a set of store rules, and every one of those moves during the year even if you ship nothing.

I have a slightly unusual view on this because of where our two app case studies ended up. Keen as Mustard, the dating app we built for a team in Sydney, was delivered on time and then the founders paused the store launch for personal reasons. Lalah, the halal food discovery app for a founder in Melbourne, is development-complete and on hold because the investor pulled out. Neither is in the stores. Both are still good examples, because a finished app that sits untouched for a year ages exactly like one that is live. It just ages quietly.

Apple and Google change the ground every year

Apple ships a major iOS version every September. Google ships a new Android version each year too. Most of the time your app keeps running on the new version. Sometimes a permission prompt changes, a layout shifts on a new screen size, or a background task stops behaving the way it did. You want to find that out on a test device in the beta period, not from a one-star review.

The bigger deadlines are the store build requirements. Google Play requires apps to target a recent Android API level, and each year it sets a cut-off after which updates that target an older level are refused (in recent years that has landed around late August). Apple, usually in spring, starts requiring new uploads to be built with a recent version of Xcode and the iOS SDK. Neither of these breaks the version that is already live. What they do is block your next update. So the day you need to push an urgent fix is the day you discover the project first needs a toolchain upgrade.

Founders find this part the most surprising. You can go months without touching the code and still be unable to ship a one-line change without a day or two of upgrade work first. I would rather do that upgrade on a calm week than in the middle of a problem.

Review guideline changes

Apple and Google update their review guidelines through the year, and the changes are not always about code. Privacy disclosures are the common one. Apple's privacy labels and Google Play's Data safety form both have to match what the app actually collects, and when you add a new SDK (say, a new analytics tool) those answers can change.

Account deletion is another. Both stores now expect apps that let people create an account to also let them delete it from inside the app. A dating app like Keen, with profiles, chat, verification and subscriptions, has a lot of data attached to one account, so deletion has to be thought through on the backend as well as the screen.

Subscription apps get extra attention from reviewers. Paywall screens, restore purchase buttons and trial wording all get checked. A rejected update is not a disaster, but it is a delay, and it tends to arrive on the week you wanted to ship something else.

Packages, Flutter versions and the slow drift

Keen and Lalah are both written in Flutter, so there is one codebase for iOS and Android. That saves a lot of duplicated upkeep. It does not remove it. Flutter itself has several stable releases a year. Every package the app depends on (maps, push notifications, subscriptions, image handling, analytics) has its own release cycle, and some of them need a newer Flutter or a newer native SDK before they will update.

Keen as Mustard is a good example of how wide that surface is. It uses RevenueCat for premium subscriptions, Firebase for the real-time parts and a Node.js backend with more than 50 API endpoints. Lalah uses the Google Maps API, Firebase for analytics and push, and its own Node.js backend. Each of those is a dependency someone else controls.

My approach is to update in small steps, often, rather than once a year in one painful jump. Skipping three Flutter versions and then trying to catch up in a weekend is how you end up with a week of broken builds. A small update every month or two is boring, and boring is the goal. You can read how we put Flutter projects together on our mobile app development page.

The backend needs looking after too

Founders tend to think of the app as the thing on the phone. Most of the moving parts are on the server. On both Keen and Lalah the backend runs on AWS, with a Node.js API in front of a database, plus the admin panel the client's team uses every day.

Over a year, the server side needs attention in a few predictable places:

• Node.js versions reach end of life on a published schedule, and hosting platforms eventually stop supporting old runtimes.
• Server packages get security fixes that should go in promptly, not at the next big release.
• Database backups should be tested by actually restoring one. A backup nobody has restored is a hope, not a backup.
• SSL certificates, domain renewals and API keys have expiry dates. Put them in a calendar with a named owner.
• Usage changes. An app with a few hundred users and one with tens of thousands need different server sizing, and someone should be watching the numbers.

None of this is glamorous, and almost none of it is visible to users until it goes wrong. Our backend development page covers how we set these systems up in the first place, which decides how much of this upkeep is easy later.

Crash reports and analytics tell you what to fix

In the first weeks after launch, real users will do things your testers did not. Keen went through 546 internal testers on TestFlight and Google Play Internal Testing before handover, which caught a lot. It does not catch everything. Real people have older phones, worse connections and habits nobody predicted.

So two things need to be running from day one. Crash reporting, which tells you which screen failed, on which device and OS version, and how often. And analytics, which tells you where people drop off. Firebase covers both for a Flutter app, and Lalah already had Firebase in place for analytics and push.

The useful habit is a short weekly look at both. Not a dashboard you admire, an actual list: the top three crashes, the step where most people give up, anything that changed after the last release. That list is what drives the next round of fixes. Without it, the next round is driven by whoever emailed most recently.

Small fixes and new features are different work

Most first-year friction I see starts here. After launch, a founder's list mixes everything together: a button that is cut off on small phones, a crash on one Android model, a new filter idea, a whole referral feature. They are not the same kind of work and they should not sit in the same queue.

Bug fixes and post-launch support are part of how we work after delivery. We don't disappear once the app is handed over. New features are a different conversation. They go back through the same steps as the original build: user stories, design in Figma, sign-off, then development. Skipping design for a "small" feature is the most common way I have seen a clean app start to feel patched together within a year.

My rule of thumb: if it changes what the user can do, it is a feature and it gets designed. If it makes something already designed work properly, it is a fix. Founders don't always love that line, but it keeps the product coherent.

Keep the handover documents current

Every project we finish ends with full handover documentation: which services the app uses, where it is hosted, how builds get to the stores, who has which access. On launch day it is accurate. Six months later, after a new SDK, a server change and a new admin user, it often is not.

It is an easy thing to let slip. The code gets updated, the document does not, and a few months later the answer to "which environment variable controls this?" lives in one developer's head. Our rule is simple. If a change would surprise someone reading the handover document, the document gets updated in the same week.

It matters most for apps like Lalah, where a product might sit paused for a while and then get picked back up. Whoever opens it next, us or another team, should be able to read one document and know what they are looking at.

If you want to talk through what the year after launch would look like for your app, our FAQ covers how we work after delivery, or you can get in touch directly.