A mobile app is never finished. Twice a year Google and Apple move the floor the app has to stand on, every quarter the framework it is built with ships a release with breaking changes, and the packages inside it are abandoned one by one. None of this is visible to the people who paid for the app until the day an update is refused or the listing quietly stops appearing to new customers. This guide puts dates and prices on all of it, for a Flutter app that talks to a Laravel backend, which is the kind we look after.
The dates below are the ones published by Google and Apple. The prices are ours, published in full, and we have shown the working.
The calendar the stores enforce
Unlike a web application, where an out-of-date framework is a risk you carry quietly, a mobile app has a third party standing between it and its users. That third party publishes deadlines and enforces them.
- Google Play, 31 August 2026. New apps and app updates must target Android 16 (API level 36). Apps that target below API 35 are hidden from new users on phones running a newer Android. Owners can request an extension to 1 November 2026 in Play Console, and after that date there is no further grace.
- Apple, since 28 April 2026. Every upload to App Store Connect must be built with Xcode 26 / iOS 26 SDK. An app that has not been rebuilt since spring 2026 cannot ship a single update, however small, until its toolchain is brought up. From 9 September 2026 the minimum deployment target is iOS 13.
- Google 16 KB pages, 1 February 2027. Updates to any app with native libraries are blocked unless it is built for 16 KB memory pages. Every Flutter and every React Native app carries native libraries, so every one of them is affected.
- Apple's inactive-app rule. Apps not updated in three years with very few downloads are removed unless an update ships within 90 days.
Those are the hard stops. They arrive roughly twice a year, in spring and late summer, and they do not negotiate.
The treadmill the frameworks add
Underneath the store calendar, the framework keeps moving.
- Flutter ships a stable release about every quarter; the current one is 3.47.7 on Dart 3.13.5. Each release carries between three and ten documented breaking changes, and the November 2026 release formally deprecates the in-SDK Material and Cupertino libraries in favour of standalone packages. The current minimums are iOS 15 and Android API 24.
- React Native releases a minor about every two months and supports only the latest three, currently 0.85, 0.86, 0.87. The Legacy Architecture was removed in 0.82 with no opt-out, so an app still on it has a migration in front of it before any routine upgrade.
- Expo gives each SDK roughly a year. The supported SDKs today are 54, 55, 56, 57; SDK 53 and below are deprecated, and SDK 54 was the last to allow the Legacy Architecture. Expo recommends upgrading one SDK at a time, so a two-year-old Expo app is five or more sequential hops.
An app that is kept current rides this treadmill in small steps. An app that is left alone for two years meets all of it at once, which is where the expensive upgrades come from.
What it costs to keep an app current
Is your Flutter app still shippable?
Send the pubspec.yaml and the store links. Within two working days a human writes back with what is overdue on the store calendar and a fixed price for fixing it.
For a Flutter app that is already current, the work is predictable: the two annual store items, a framework and dependency bump each quarter, the store metadata rules as they change, and the odd crash to chase. We sell that as a module on top of the care plan for the Laravel application behind the app, because the two have to move together. The module is priced as the extra hours it adds.
| Care plan | Mobile module | Added hours | What it covers |
|---|---|---|---|
| Essentials ($500 per month, 6 hours) | +$300 per month | 3 hours | One Flutter app pair kept shippable. |
| Standard ($900 per month, 12 hours) | +$450 per month | 6 hours | Current, and moving: monthly releases from your backlog. |
| Partner ($1,500 per month, 24 hours) | +$600 per month | 8 hours | Release pipeline owned, a second app covered. |
Care plans start at $500/month and run month to month after a three-month minimum. The module has one precondition: the app must already be current. It does not absorb a backlog, for the same reason a care plan does not absorb a Laravel upgrade.
What it costs to catch up
If the app has fallen behind, the first job is a fixed-price upgrade, and the size depends on how far behind it is.
- Second-opinion review, $750, 5 working days. A written architecture and store-compliance report for any Flutter or React Native app. Credited against any work that follows. This is also the only way we take on a React Native app.
- Store-Compliance Sprint, $2,500–$3,500, 7–10 working days. A Flutter app no more than two stables behind, brought back to a shippable state on both stores.
- Catch-up Upgrade, $6,000–$12,000, 3–5 weeks. An app two or more years behind: migrations done, discontinued packages replaced, tests backfilled.
For context, Callstack, the consultancy that contributes to React Native itself, says most React Native upgrades take one to three weeks and cites an app two years behind that needed 52 breaking changes resolved. Our Catch-up band assumes the same order of effort for a Flutter app that has skipped the null-safety or design-library migrations. If a quote you receive elsewhere is a few hundred dollars for that work, ask what is being skipped; usually it is the tests, and the next owner pays for them.
Sprint or catch-up: how to tell
- The app was last released within the past year and builds on a current machine: sprint.
- The
pubspec.yamlpins a Flutter version more than two stables old, or any package it depends on is marked discontinued on pub.dev: catch-up. - A React Native app still on the Legacy Architecture, or an Expo app more than two SDKs behind: review first, then catch-up.
- Nobody can say which version it is on: send us the manifest and we will tell you.
Whose accounts, whose keys
One rule shapes all of this work: the app is submitted from your Apple and Google accounts, never ours. Apple's guidelines require apps to be submitted by the entity that owns them, and only your Account Holder can sign agreements or create API keys. We work inside your accounts with the least access the job needs, your signing keys stay in your custody, and store review time sits outside our response clock, because we do not control it. The full set of clauses is on the upgrade page.
Find out where your app stands
Send us the pubspec.yaml (or package.json) and the store links on the mobile app upgrade page. A human writes back within two working days with the dates that apply to your app and the package that fits. If the app is already current, the honest answer is the Mobile module on a care plan; if it is not, the fixed prices are published.
Frequently asked questions
Our backend is not Laravel. Can you still look after the app?
Not for now. The module exists because the Laravel application and the Flutter app have to be upgraded together; without the backend under care we would be looking after half a system. We will say so and point you elsewhere.
Do you do React Native?
We work in React Native and Expo, but we have not yet published a React Native case study, so we quote React Native work only after the paid review.
What about Flutter web?
If your app ships a Flutter web admin, kiosk or dashboard, the module keeps it building; recent Flutter releases removed the HTML renderer and old browser APIs, which silently breaks stale web builds. We do not build public marketing sites in Flutter web, and we would not recommend it.
What if Google or Apple reject an update for a reason that is not technical?
Rejections on content, legal, business-model or design grounds are outside the module and quoted separately. The module covers the rules that need toolchain, SDK or metadata work: target API, Xcode floor, privacy manifests, age ratings, trader status and the 16 KB pages.