One Flutter codebase runs on both iOS and Android. That's the appeal. But it also means one maintenance retainer covers both platforms — and when Flutter ships a breaking change, both stores are affected simultaneously. We keep your Flutter app current with each SDK release, handle pub.dev dependency conflicts, and maintain Play Store and App Store compliance from one team that knows your codebase. From £675/month.
Flutter's cross-platform model means one maintenance retainer covers both iOS and Android. The same engineer who handles your Play Store compliance handles your App Store submission — no coordination overhead, no separate contracts. Flutter maintenance typically takes 10–15 hours per month compared to 25–40 hours for separate native apps. The cost efficiency of Flutter development carries through into the maintenance phase.
The maintenance complexity is real. Flutter ships multiple stable releases per year, each with documented breaking changes that affect both platforms simultaneously. Flutter 3.38 required Java 17 for Android builds, mandatory UIScene lifecycle support for iOS, and changes to edge-to-edge inset handling. The pub.dev dependency tree adds to this — most Flutter apps have 20–50 packages, some with native iOS and Android platform channels that can break independently of the Flutter SDK. Someone needs to own this continuously, not just when a release deadline is approaching.
We take over Flutter apps from version 2.x onwards, including apps from other agencies or freelancers, apps with deferred SDK upgrades, and codebases that have never had active dependency management. Onboarding starts with a structured code review: Flutter SDK version, full pub.dev dependency health, native platform channel status on both iOS and Android, current crash data, and any Dart deprecations heading towards hard errors. We document everything and scope any remediation separately before the retainer begins. Onboarding takes 3 to 5 working days. From £675/month, 3-month minimum.
If you need broader platform coverage including React Native or native iOS/Android, our cross-platform App Care retainer covers multi-platform agreements under one contract.
Written by Gareth Reese, Founder and CTO of Foresight Mobile. Gareth oversees App Care engagements and has led Flutter maintenance transitions from offshore agencies, departing developers, and post-App Rescue stabilisation projects.
An actionable four-week plan with clear deliverables and an unbeatable £3,500 price point, credited against your first development sprint.
Total client time commitment: 5-7 hours across 4 weeks
We meet with your key stakeholders to understand your business goals, user needs, and technical constraints. You'll share any existing research, designs, or documentation you have.
Our engineering team assesses the technical feasibility, identifies integration points with your existing systems, and evaluates architecture options.
We determine whether Flutter, native development, or another approach makes the most sense for your specific requirements.
We create clickable prototypes so you can experience your app before it's built. You'll test navigation flows, validate the user experience, and gather feedback from stakeholders.
Alongside this, we prioritise features based on business value and technical complexity, mapping out a phased delivery plan with a detailed cost estimate.
You receive your complete Gameplan pack, plus a presentation walkthrough with Q&A. Your team walks away with everything needed to make a confident decision.
A named Flutter team who tracks SDK releases, resolves dependency conflicts before they block your updates, and handles compliance on both iOS and Android simultaneously.
Taking over Flutter apps from offshore teams is one of the most common situations we handle. Flutter's cross-platform appeal makes it a popular choice for offshore development agencies, which means a significant proportion of Flutter apps in the UK market were built by teams in India, Eastern Europe, or South-East Asia who are no longer the right fit for ongoing support. The handover challenges are predictable: deferred SDK upgrades, dependency trees that haven't been touched since launch, platform channels that were set up correctly at the time and are now unmaintained, and documentation that lives in a Notion workspace you may or may not have access to.
We start every Flutter takeover with a code review covering: current Flutter SDK version vs latest stable, full pub.dev dependency audit, native platform channel status on both Android and iOS, current crash data if any monitoring is configured, and any Dart deprecations heading towards hard errors in the next SDK release. We document everything we find and scope any remediation work separately before committing to the retainer.
Onboarding takes three to five working days. We support Flutter apps from Flutter 2.x onwards and have handled migrations from very early Flutter versions with sound null safety retrofits, complete dependency replacements, and platform channel rewrites.
Structured Codebase Review • Dependency Tree Audit • Platform Channel Assessment • 3–5 Day Onboarding • Flutter 2.x Migration Support
Some Flutter clients genuinely only need maintenance: OS updates, dependency management, compliance work, and someone to call when something breaks. That's a perfectly valid requirement and it's what the Essentials retainer covers. Others want the same team that maintains the app to also build new features — which is worth considering, because the team that knows your state management architecture is the team best placed to extend it without introducing regressions.
When we build new features alongside maintenance, feature work is scoped and priced separately from the retainer so you always know what you're paying for maintenance versus development. The maintenance commitment doesn't change when there's active feature work in progress. We don't deprioritise OS updates because a feature sprint is running.
The Flutter single-codebase model makes this particularly efficient: a new feature built in Flutter ships to both iOS and Android from a single review cycle. Compare that to a native approach where a new feature requires two separate implementations, two sets of QA, and two App Store / Play Store submissions. That efficiency carries through to the maintenance side too.
Maintenance-Only Plans Available • Feature Work Scoped Separately • Single Codebase Dual-Platform Feature Delivery • No Upsell Pressure
Flutter apps have a single Dart runtime but two distinct native layers underneath. Crashes can originate in Dart code, in a native Android platform channel, in an iOS plugin, or in the native rendering layer. We configure Firebase Crashlytics with separate iOS and Android crash streams so that a Samsung-specific crash doesn't get averaged out across the iOS user base, and an iOS-only regression isn't hidden in Android-dominated crash data.
Our crash-free rate target for maintained Flutter apps is above 99%. When a new crash pattern appears — often after a Flutter SDK update, a dependency bump, or a device-specific OS release — we investigate using the full Crashlytics stack trace including the Dart stack and the native layer. We fix at the right level: Dart code issues in Dart, platform channel issues in the native layer.
Performance monitoring tracks the other failure mode that doesn't produce crash reports: widget rebuild frequency, frame rendering time, and jank patterns. Deep widget hierarchies and unnecessary rebuilds are the most common production performance issues in Flutter apps as they grow. We catch these in monthly performance reviews before they accumulate into noticeable user experience degradation.
Firebase Crashlytics • Separate iOS and Android Streams • 99%+ Crash-Free Target • Frame Rendering Monitoring • Jank Detection
Flutter apps face the same compliance requirements as native apps on both platforms simultaneously. The App Store has Privacy Manifest requirements, Xcode SDK submission deadlines, and annual iOS compatibility updates. The Play Store has target API level requirements (Google advances the deadline each August), Android Vitals monitoring, and the 16KB memory page size requirement introduced in 2026. When Flutter introduces a change that affects both — like the Java 17 Android requirement — both compliance timelines are affected at once.
We handle both compliance tracks under a single retainer. That means testing against Apple's iOS developer betas from June each year, managing your Play Store targetSdkVersion ahead of Google's August deadline, maintaining the Privacy Manifest for the iOS submission, and monitoring Android Vitals for crash and ANR rate. When a compliance requirement affects the Flutter SDK itself (as UIScene support did in Flutter 3.38), we track it through the Flutter release notes and apply it at the SDK level rather than patching around it.
The practical advantage of this unified approach: when both stores have updates in the same sprint, there's one set of release notes, one QA cycle, and one submission window to coordinate — not two separate workflows with separate handoff points.
App Store Compliance • Play Store API Level • Privacy Manifests • Android Vitals • Single QA Cycle for Both Platforms
A typical Flutter app has 20–50 pub.dev dependencies. Some are pure Dart with no platform code; others include native Android and iOS plugins that can break independently of the Flutter SDK when Google or Apple changes an underlying API. Flutter's official guidance recommends running your full test suite after every dependency upgrade — because flutter pub upgrade "can result in significant changes to the versions of packages your app relies on, which might introduce breaking changes."
We run monthly dependency audits using flutter pub outdated, review every update for documented breaking changes, and apply updates in batches that are tested before they reach the main branch. When a dependency has a native platform layer, we verify compatibility on both Android and iOS before updating, not after a production crash report tells us something went wrong.
For packages that have been abandoned by their authors — a real and common occurrence in the pub.dev ecosystem — we either fork and maintain them ourselves, migrate to an actively maintained alternative, or write a small wrapper to abstract the dependency so future replacement is less disruptive. We don't leave your app dependent on unmaintained code.
Monthly Dependency Audits • flutter pub outdated • Native Plugin Compatibility • Abandoned Package Strategy • Breaking Change Review
Flutter releases multiple stable versions per year, each with a documented list of breaking changes and migration guides. Flutter 3.38 required Java 17 for Android builds, mandatory UIScene lifecycle adoption for iOS (per Apple's WWDC25 mandate), and changes to edge-to-edge inset handling that affected any app with custom bottom navigation. Each of these is well-documented — but acting on the documentation requires someone who knows the codebase and has time to run the migration properly.
We track every Flutter stable release, review the breaking changes list against your specific dependency tree and codebase, and handle the migration work before it becomes an update blocker. For major version jumps, we test in a branch before merging to main so there's always a known-good version to fall back to. For minor releases, we assess the risk and apply updates on the standard monthly maintenance cycle.
Flutter's migration guides are thorough, but they describe what to do, not how long it takes for a specific app. In our experience, the work that takes an afternoon on a simple app can take two to three days on a complex one with a large plugin surface area. We scope that accurately rather than treating SDK updates as trivially fast.
Current Flutter Stable • Migration Guide Execution • Branch-Based Testing • Java 17 Compliance • UIScene Lifecycle
Our standard Flutter onboarding takes three to five working days from when we have codebase access. The process covers: code review (Flutter SDK version, dependency health, native platform channels on both iOS and Android, any Dart deprecations), setting up Firebase Crashlytics with separate iOS and Android streams, configuring any missing CI/CD pipelines, documenting the architecture, and taking over any active support tickets.
The one-off onboarding fee is £500 to £1,000 depending on the complexity of the app and the state of the existing infrastructure. Apps coming from offshore teams often need more documentation work and sometimes need CI/CD setup from scratch; apps from in-house developers who kept good records typically need less. We assess the scope during the initial conversation and give you a fixed onboarding price before we start.
After onboarding, the rolling monthly retainer begins. The initial period is three months, after which it's rolling monthly with no long-term commitment.
pub.dev is Flutter and Dart's package repository — the equivalent of npm for JavaScript or CocoaPods for iOS. Most Flutter apps depend on 20–50 pub.dev packages for features like state management, authentication, payments, analytics, and device APIs. These packages need regular updates, and updates can introduce breaking changes.
Flutter's official guidance warns explicitly that upgrading packages "can result in significant changes to the versions of packages your app relies on, which might introduce breaking changes," and recommends running your test suite after every upgrade. In practice, many Flutter apps are deployed without a test suite, which means dependency updates carry higher risk than they should.
A proportion of pub.dev packages are also abandoned by their authors — they stop receiving updates, accumulate compatibility issues with new Flutter and Dart versions, and eventually become blockers. When we encounter an abandoned package in a maintained app, we either fork and maintain it ourselves, migrate to an alternative, or write a wrapper to abstract the dependency. We don't leave apps blocked on unmaintained code.
Flutter publishes breaking changes and migration guides for every release. When an update introduces a breaking change that affects your app, the process is: identify which of your code and dependencies are affected, apply the migration steps in a feature branch, run the test suite, test on both iOS and Android devices, and merge when we're confident it's clean.
For straightforward breaking changes (a renamed API, a changed constructor signature), this is typically a few hours of work. For complex migrations — like the UIScene lifecycle requirement in Flutter 3.38 that affected how iOS apps handle app lifecycle events — it can be two to three days of careful work with both iOS and Android regression testing.
We handle this as part of the monthly retainer for routine SDK updates. For major version jumps with significant migration work, we scope the effort in advance so you know what's coming. We never apply a breaking change update to a production app without branch-based testing first.
Yes. Flutter's single-codebase model means one maintenance retainer covers both iOS and Android. The same code, the same dependency tree, the same build pipeline — we maintain all of it under one agreement rather than splitting it into separate iOS and Android retainers.
This includes both compliance tracks: App Store submission requirements (Xcode SDK compliance, Privacy Manifests, iOS beta testing) and Play Store requirements (target API level, Android Vitals monitoring, Google Play policy compliance). When both stores need attention in the same month, it's one engineer, one sprint, one set of release notes.
The pricing reflects this: a Flutter App Care retainer at £675/month covers both platforms. If you were maintaining a native iOS app and a native Android app separately, you'd be managing two retainers, two compliance calendars, and two separate engineering relationships.
Yes. Taking over Flutter apps from other agencies, offshore teams, and departing freelancers is one of the most common situations we handle. The process is the same regardless of who built it: a structured code review covering Flutter SDK version, dependency health, native platform channel status on both iOS and Android, and current crash data if monitoring is configured.
We document everything we find. If there's remediation work needed before we can safely maintain the app — deferred SDK upgrades, conflicting dependencies, unmaintained platform channels — we scope it separately so you know what it costs before committing to the retainer.
We've taken over Flutter apps from very early versions (Flutter 1.x and 2.x) through to current stable releases, including apps that needed retrospective null safety migrations and apps that needed complete dependency tree replacements.
Flutter app maintenance in the UK typically costs between £675 and £1,495 per month on a retainer. Our App Care retainers for Flutter start at £675/month and cover both iOS and Android under a single agreement.
Flutter's cross-platform model means one maintenance retainer covers both platforms — which compares favourably to maintaining separate native iOS and Android apps. Flutter maintenance typically requires 10–15 hours of engineer time per month, compared to 25–40 hours for separate native apps covering the same platform footprint. The industry benchmark of 15–25% of original development cost per year still applies, but the development cost for a Flutter app is typically lower than two separate native apps, and the maintenance cost follows the same pattern.
The one-off onboarding fee (code review, monitoring setup, documentation) is £500 to £1,000 depending on the complexity of the app and the state it's in when we take it over.
Flutter app maintenance covers the ongoing work to keep a cross-platform app functional, current, and compliant across both iOS and Android. Core elements include: Flutter SDK version management (applying updates and handling breaking changes migrations), pub.dev dependency maintenance, dual-platform App Store and Play Store compliance, crash monitoring via Firebase Crashlytics with separate iOS and Android streams, and a shared Slack channel with a named Flutter engineer.
A full retainer also typically covers: performance monitoring (frame rates, widget rebuild frequency), monthly health reports with dependency updates and crash trend analysis, backend API monitoring if the app connects to your own infrastructure, and handling compliance notifications from Apple and Google.
Some retainers include feature development alongside maintenance. This is optional — maintenance-only plans are available for clients who just need the app kept healthy without active development.
At minimum, a Flutter app needs maintenance every time Flutter ships a stable release with breaking changes — which happens multiple times per year. Flutter publishes a breaking changes and migration guides page for every release, and changes in one release compound if deferred to the next.
In practice, monthly maintenance work covers: dependency updates using flutter pub outdated, reviewing and applying Flutter SDK updates, handling any App Store or Play Store compliance notifications, monitoring crash reports from both iOS and Android streams, and addressing any performance regressions from device OS updates.
Apps that haven't been actively maintained for over a year typically need a one-off remediation sprint before moving to a regular retainer — to bring the Flutter SDK version current, resolve dependency conflicts that have accumulated, and address any Dart deprecations that are approaching hard-error status in current Dart versions.
You've got a working app and nobody reliable to look after it. Maybe your developer handed in their notice. Maybe the offshore team stopped responding. Maybe the freelancer who built it has gone quiet at the worst possible time.
App Care onboarding gets you from that situation to a UK-based team who knows your codebase inside out, with a shared Slack channel and agreed response times. The onboarding fee is typically £500 to £1,000 depending on complexity. After that, you're on a rolling monthly retainer from £675/month with no long-term lock-in after the initial three months.
We start with a short call to understand what your app does, what platforms it runs on, and what the handover situation looks like. Then we request access to the repository (GitHub, GitLab, or Bitbucket), your App Store Connect and Google Play accounts, and any backend infrastructure. If a departing developer is still available, we'll use some of that time to fill in gaps. If not, we work from the code.
We review the architecture, third-party dependencies, security posture, and anything that looks fragile. If there's technical debt that needs fixing before we can support the app properly, we scope that separately so you know what it'll cost. We also build internal documentation covering how the app is structured, where the critical logic lives, and how deployments work.
We instrument the app with Firebase Crashlytics and Sentry for crash reporting, and set up Datadog for backend API monitoring where applicable. We configure CI/CD pipelines, TestFlight distribution for iOS builds, and deployment processes that don't rely on a single developer's laptop. Snyk and SonarQube scans catch dependency vulnerabilities and code-level security issues before they become incidents.
Your retainer covers OS updates, security patches, App Store compliance, crash investigation, and proactive monitoring. Feature work is scoped and priced separately so you always know what you're paying for. The initial commitment is three months, then rolling monthly with no long-term lock-in. You stay because the service is good, not because you're contractually stuck.
Your app, your way. Here's how we make it happen.
Fixed price agreed upfront, with regular progress calls and live demos so you always know where your project stands.
From first build to App Store submission and beyond, we offer App Care retainers from £675/month so your app keeps pace with your business. We're with you all the way.
Real users from your target audience test your app throughout development, not just at the end. Their feedback shapes decisions before they become expensive to undo — so you launch with confidence rather than hope.
You know your business. We know how to build apps that succeed. The two together is where good products come from.
Our founder has been building mobile products since 2003, and our core team has been together since Foresight launched in 2017.
We're based in Manchester with offices in London and Birmingham, and believe face-to-face time makes better products. Drop in whenever you like.
