After launch
Flutter App Maintenance: What Keeps a Flutter App Working, Year After Year
Flutter app maintenance is the work that keeps a live app accepted by the stores, safe on new phones and ready for the next feature. It is quieter than the build and easy to postpone, until an update is rejected or a release breaks on the newest iPhone. This guide shows what a maintenance year looks like, what breaks when it is skipped, how to check the health of your app, and the three ways to organise it.
Short answer
Flutter app maintenance means keeping the Flutter version, the packages, the iOS and Android build tools and the backend up to date, meeting the yearly requirements of Apple and Google, fixing issues reported from real devices and keeping the codebase ready for new features. In practice it is a steady rhythm: small updates every few weeks, a larger review each quarter and one bigger upgrade a year when the stores raise their requirements. Skipping it rarely breaks the app overnight; it makes the next update slow, risky or impossible to publish.
Key takeaways for app owners
- The stores set the calendar. Apple and Google raise their build requirements every year, and updates that miss them are not accepted.
- Small and often beats big and late. A Flutter upgrade done every quarter takes hours; one postponed for two years can take weeks.
- Packages are the hidden risk. Each plugin your app depends on ages at its own pace.
- Maintenance protects the next feature. A healthy codebase is the difference between adding a feature and rebuilding first.
What Flutter app maintenance actually covers
A Flutter app is one codebase, but it lives on top of several moving parts. Maintenance is the work of keeping all of them in step.
- The Flutter SDK and Dart. Flutter ships stable releases several times a year. Staying within a release or two keeps upgrades small and keeps the app compatible with new tools.
- Packages and plugins. Payments, maps, notifications, sign in and analytics all come as packages. Each one has its own updates, deprecations and, sometimes, abandonment.
- Native build tools. Xcode and the iOS SDK on one side, Gradle, the Android SDK and target API level on the other. These are what the stores check.
- Store requirements and policies. Privacy declarations, account deletion, permissions wording and payment rules change and are enforced at review.
- The backend and third party services. API versions, database plans, certificates and keys that expire or change.
- Real device issues. Crashes, slow screens and layout problems reported from phones and OS versions nobody tested at launch.
If the app was built by one team end to end, these parts were chosen together and are easier to maintain together. That is one reason we treat maintenance as part of what a Flutter app development company should offer, not as an afterthought.
A Flutter app maintenance year at a glance
The exact dates move, but the shape of a year is consistent. Most of the work is small and regular; one or two moments a year are larger.
Small releases
- Fixes from crash reports
- Minor package updates
- Small improvements from users
Health review
- Flutter and Dart upgrade
- Package audit and replacements
- Performance check on older phones
Store season
- New Xcode and iOS SDK
- New Android target API level
- Updated privacy declarations
Unplanned work
- A service changes its API
- A certificate or key expires
- A policy change at review
Google publishes its yearly target level rules in the Google Play target API requirements; Apple announces its SDK minimums each spring for updates submitted later in the year. Both are predictable, which is why the store season belongs in the plan rather than in a crisis.
What breaks when Flutter app maintenance is skipped
An unmaintained app usually keeps running for a while. The cost shows up the next time you need to change something.
From a project we maintain
A trainer booking app we look after was ready for an update when Apple's new requirement came into force: updates had to be built with the latest iOS SDK and Xcode. The release could not be submitted until the project was moved to the new tools and the build settings that changed with them were corrected.
None of it was difficult, and it did not affect users. But it is exactly the kind of work that turns a planned Tuesday release into a week of delay if nobody saw the deadline coming.
The lesson we took from it is simple: the store season goes into the maintenance calendar as soon as Apple and Google announce their requirements, and the upgrade is done weeks before the deadline, not in the week of a planned release.
Flutter app maintenance is cheap when it is regular and expensive when it is postponed. The work is the same; only the timing changes.
Not sure how healthy your Flutter app is? Send us the repository and we will tell you what needs attention first.
A quick health check for your Flutter app
Use this to judge where your app stands today. Mark each point you can honestly confirm today. The more of them you can tick, the cheaper your next update will be.
Check the version in the project against the current stable release.
A fresh build on a clean machine works without manual fixes.
Each plugin has had an update in the last year and no open warning about abandonment.
Someone looks at crashes every week, not only after a bad review.
Expiry dates and owners are written down, and accounts are in your company name.
A change to one screen cannot silently break sign in or payments.
If several of these are unclear, the first step is not a feature. It is a short review of the codebase, the build and the accounts. When the app comes from another team, that review is the start of taking over an existing mobile app.
Three ways to organise Flutter app maintenance
There is no single right model. The right one depends on how often the app changes and who owns the code.
Ongoing plan with the team that built it
A monthly or quarterly plan that covers updates, the store season, monitoring and a set amount of small changes.
Fits: apps that earn money or run daily operations, with no in house mobile developer.
Your own developer
An in house developer owns the code and the releases, with the original team on call for larger changes.
Fits: products with a roadmap that needs continuous work and someone to lead it.
Updates on demand
Work is ordered when needed, for example before the yearly store deadline or when a feature is added.
Fits: stable internal tools that change rarely and can tolerate a short delay.
Many companies move between these models over time. A new product usually starts on an ongoing plan with the team that built it, then shifts to its own developer once the roadmap and the budget justify a hire, with the original team still available for the yearly store season and larger changes.
Whichever model you choose, the code, the store accounts and the backend should be in your name, and the codebase documented well enough that another team could pick it up. What a structured plan includes is described on our mobile app maintenance services page, and the yearly budget side is covered in mobile app maintenance cost.
Maintenance and new features in the same Flutter codebase
Most apps need both at once: keeping the existing app healthy and adding what users ask for. The two should share one plan, because a feature built on an outdated codebase often has to start with an upgrade.
A well maintained Flutter app can take substantial new work without a rewrite. In one project we added a new onboarding path, sign in with Apple, Google and phone number, and a subscription paywall inside a live Flutter app in about a month. That was possible because the existing code was in good shape. On Liniowiec, the second stage is being built on the same codebase as the first, which is the outcome good maintenance protects.
If you are planning new features on an existing app, our guide to adding features to an existing Flutter app explains how we assess the code before quoting.
Flutter apps from our portfolio, and what keeping them healthy meant
Three Flutter products we built, each with a different reason why maintenance mattered after launch.
EveSport
Trainer booking, Flutter and SupabaseBookings, slot swaps, chat and payments. Store requirements and payment packages are what keep updates moving through review. Case study
Liniowiec
Offline river navigation, Flutter and NestJSOffline sync and maps that must work on the water. The second stage is built on the same codebase, which is what a healthy codebase allows. Case study
TimeFix
Crew app for electrical contractors, FlutterA work timer that keeps running with the screen locked or during a call. Background behaviour like this is the first thing to test after every iOS and Android release. Case study
What a quarterly Flutter upgrade looks like in practice
A regular upgrade is unremarkable, and that is the point. For a typical app it takes a day or two of work, done in a separate branch so nothing reaches users until it is tested.
- Read the release notes. Check what changed in Flutter, Dart and the main packages since the last upgrade, and flag anything marked as breaking.
- Upgrade in small steps. Move Flutter first, then the packages one group at a time, so that any problem has an obvious cause.
- Run the tests and the core flow. Automated tests catch most issues; a manual pass on a real iPhone and a real Android phone catches the rest.
- Check performance on an older device. Upgrades occasionally change rendering or memory use, and older phones show it first.
- Release with a small change users can see. Pairing the upgrade with a minor improvement keeps the release rhythm natural and the store history clean.
When upgrades happen every quarter, each one touches only a few months of changes. When they are postponed for two years, every one of those steps becomes a project.
Flutter app maintenance by type of app
The basics are the same for every app, but what deserves the most attention depends on what the app does.
- Booking and marketplace apps. Payments, notifications and store payment rules carry the risk. A broken push notification means missed bookings, and a payment package that falls behind can block an update during review.
- Field and offline apps. Local storage, sync and background behaviour are sensitive to operating system changes. Every major iOS and Android release deserves a test on real devices in poor coverage, not only on a desk.
- Subscription apps. In app purchase libraries and store billing rules change regularly, and a mistake here costs revenue directly. Test purchase, renewal and restore after each upgrade.
- Internal company tools. They change less often, but they are often distributed through device management and depend on company sign in. Certificates and identity settings are the usual surprise.
Questions to ask before you agree on Flutter app maintenance
- What exactly is included? Store season upgrades, package updates, monitoring, a number of small changes, or only fixes.
- How fast is a critical issue handled? A crash in the payment flow needs a different response time than a typo.
- Who watches the store deadlines? Someone should know the next Apple and Google requirements before they arrive.
- Who has access to what? Repository, store accounts, backend and crash reporting, all in your company's name.
- How are bigger changes priced? New features should be quoted separately, so maintenance stays predictable.
About the source
Who is answering this?
- Company
- Apps Value, mobile app development agency
- Location
- Cracow, Poland
- Markets served
- United States, Western Europe, Nordics
- Experience
- 6 years, 19+ projects delivered, 13+ positive client reviews
- Technologies
- Flutter, React Native, NestJS, Supabase, PostgreSQL, AWS, Google Cloud
- Flutter apps we maintain
- Booking, marketplace, field and navigation apps
FAQ
What does Flutter app maintenance include?
Keeping the Flutter SDK, Dart and packages up to date, rebuilding with current Xcode and Android tools, meeting yearly store requirements, fixing issues from crash reports, keeping keys, certificates and accounts in order, and keeping the backend and third party services current.
How often should a Flutter app be updated?
Small updates every few weeks, a Flutter and package upgrade each quarter, and one larger update a year when Apple and Google raise their requirements. Regular small upgrades are much cheaper than one large upgrade after a long pause.
What happens if a Flutter app is not maintained?
It usually keeps running for a while, but the next update can be rejected by the stores, packages may stop compiling, and an upgrade after a long pause can take weeks of work before any new feature can be added.
Can you maintain a Flutter app built by another team?
Yes. We start with a review of the codebase, the build, the packages and the accounts, then agree on a plan. If something needs fixing first, the review shows what and why before any ongoing work begins.
Is Flutter app maintenance more work than native maintenance?
Usually less, because one codebase serves iOS and Android, so most updates are made once. The native build tools for both platforms still need attention every year.
Does Flutter app maintenance include new features?
Usually only small improvements. A maintenance plan keeps the app healthy and accepted by the stores and may include a set amount of small changes. Larger features are scoped and priced separately, so the maintenance budget stays predictable and new work gets a proper estimate.
Who should own the code and accounts during maintenance?
Your company. The repository, store accounts, backend and crash reporting should be in your name, with access granted to the team that maintains the app.
Related guides
Written by
Thomas Siudut
Co-Founder and CEO, Apps Value
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Have a Flutter app that needs looking after?
Tell us how old the app is, who built it and what you want to change next. We will tell you what needs attention first, how we would maintain it, and what a fixed price for that work covers.