On this page · 13 sections
- Question 1: what stable release are you on, and what is the cadence?
- Question 2: what did you do about Impeller?
- Question 3: are you off CocoaPods yet?
- Question 4: what is your plan for Material and Cupertino leaving the SDK?
- Question 5: which OS floors did you just lose?
- Question 6: how are you handling the store deadlines?
- Question 7: what evidence do you have, and what do you not have?
- Governance: who actually maintains this now
- India-specific considerations
- What we build, and how the engagement runs
- FAQ
- How eCorpIT can help
- References
Summary. Flutter 3.47 reached stable on 12 August 2026, alongside Dart 3.13, on a published cadence of four stable releases a year. That release made Impeller the default renderer on macOS, Windows and Linux, raised the iOS minimum from 13 to 15 and macOS from 10.15 to 12, and confirmed that the Material and Cupertino design libraries are scheduled for formal deprecation in the November 2026 stable release. Google Play requires new apps and updates to target API level 36 from 31 August 2026. Apple has required the iOS 26 SDK for App Store Connect uploads since 28 April 2026. Google reported over 1.5 million monthly Flutter developers at I/O 2026, up 50% year on year.
None of that is exotic. All of it is public. And a Flutter partner who cannot walk you through it is going to hand you a codebase that needs three forced migrations in its first year.
The useful way to evaluate a Flutter company in 2026 is not to look at their portfolio. It is to ask them what is about to break.
Question 1: what stable release are you on, and what is the cadence?
The current stable is Flutter 3.47.0, listed at the top of the Flutter release notes, with 3.44.0, 3.41.0 and 3.38.0 behind it. Dart 3.13.0 shipped the same day; the Dart what's new page records "Released on: August 12, 2026" and covers changes from 18 May 2026 onward. Its headline language feature is primary constructors, which we covered when it landed in Dart 3.12 primary constructors and dot shorthands.
The cadence is published a year ahead. Flutter's install archive lists the 2026 schedule as 3.41 in February, 3.44 in May, 3.47 in August and 3.50 in November, each with a branch cutoff roughly five weeks before release, and notes that roughly every third beta is promoted to stable.
That matters commercially because it makes maintenance predictable and therefore quotable. A partner proposing an annual "upgrade project" is either padding or has not read the schedule. Four stable releases a year, absorbed continuously, is a small standing cost. Four skipped, absorbed at once, is the expensive version.
Ask which release their last three delivered projects run on. If the answer is more than two stables behind, ask why.
Question 2: what did you do about Impeller?
Impeller has quietly finished replacing Skia almost everywhere. Flutter's Impeller documentation is unambiguous by platform.
On iOS, "Impeller is the only supported rendering engine on iOS with no ability to switch to Skia." On Android, it "is available and enabled by default on Android API 29+", falling back to the legacy OpenGL renderer on lower versions or devices without Vulkan, with an opt-out still available through --no-enable-impeller or the io.flutter.embedding.android.EnableImpeller manifest key. On macOS, Windows and Linux the documentation now reads that Impeller "is available and enabled by default as of Flutter 3.47" and that "in a future release, the ability to opt out of using Impeller will be removed."
Web is the exception. Flutter on the web still uses Skia and "might use Impeller in the future."
A partner who shipped a desktop Flutter app before August 2026 has a renderer change to validate, particularly around custom shaders and platform views. One who does not know that is not tracking the engine. We wrote about this transition when it became mandatory on mobile in Impeller becoming mandatory on Flutter Android and iOS.
Question 3: are you off CocoaPods yet?
This is the cleanest single test of whether a partner is current, because it has a public scoreboard.
Swift Package Manager replaced CocoaPods as the default dependency manager for iOS and macOS Flutter apps in Flutter 3.44. The Flutter 3.47 release post states that "because CocoaPods is now in maintenance mode, plugins that do not migrate to SwiftPM will eventually stop working", that unmigrated plugins "also receive lower pub.dev scores", and that 92 of the top 100 iOS plugins have now migrated.
The scoreboard is the useful part. If a partner's proposed plugin list includes packages still on CocoaPods, that is a visible, checkable risk in the estimate rather than an argument about quality. Our walkthrough of the mechanics is in the CocoaPods sunset and SwiftPM migration for iOS and Flutter.
Question 4: what is your plan for Material and Cupertino leaving the SDK?
This is the largest forced migration on the Flutter horizon and it is three months away.
The Flutter 3.47 release post states that "the original design libraries inside the core SDK are scheduled for formal deprecation in the upcoming Fall stable release in November." Flutter provides an automated path, dart fix --apply --code=migrate_design_widgets, and the direction was set out in the 2026 Flutter and Dart roadmap, which describes "decoupling the Material and Cupertino design systems into standalone packages" as part of moving to an open and sustainable operating model.
Automated migrations handle the common cases and leave the interesting ones. Heavily themed apps, custom widget subclasses and anything that reaches into Material internals will need hands on it. A partner quoting a fixed-price build for delivery in Q4 2026 without a line for this migration is quoting a number they will come back to renegotiate. We set out the detail in the Flutter Material and Cupertino UI package migration.
There is a related survey signal worth knowing. Flutter's Q2 2026 developer survey, run 8 to 22 June 2026 with over 3,500 complete responses, reported 93% positive satisfaction overall and trust in Flutter rising from 77% to 83%, but recorded that "Cupertino widgets dropped 6 points to 61% top-2 box, marking the steepest decline anywhere in the survey." The iOS-fidelity story is the soft spot, and it is the one being restructured.
Question 5: which OS floors did you just lose?
Flutter 3.47 raised minimums, and that has product consequences before it has engineering ones.
The 3.47 release post records the iOS minimum moving from 13 to 15 and macOS from 10.15 to 12, the latter explicitly to support Xcode 27. The current supported platforms matrix gives Android 24 to 37 supported with 23 and earlier unsupported, iOS 15 to 26 supported with 14 and earlier unsupported, macOS Monterey through Tahoe, Windows 10 and 11, and web on the latest two versions of Chrome, Edge and Firefox plus Safari 15.6 and above.
Android toolchain requirements moved with it. The 3.47 post pins Java 17 as the minimum, KGP 2.4.0, AGP 9.1.0 and Gradle 9.3.1, with compileSdkVersion and targetSdkVersion defaulting to API 36 and minSdkVersion to API 24. The Kotlin plugin change is a hard build break, not a warning: Flutter's built-in Kotlin migration guide states that "built-in Kotlin is the default in AGP 9 and later. Apps that use the kotlin-android plugin, also known as the Kotlin Gradle Plugin (KGP), will fail to build." Our migration notes are in the Flutter AGP 9 and KGP migration decision.
One more, driven by Apple rather than Flutter: the 3.47 post warns that "the iOS 27 SDK now mandates the UIScene lifecycle for all UIKit-based apps. Apps built with Xcode 27 that do not adopt UIScene will fail to launch on startup."
| Migration | Landed or lands | Nature | Automated path |
|---|---|---|---|
| Impeller on desktop | Flutter 3.47, Aug 2026 | Default renderer, opt-out to be removed | None; requires validation |
| CocoaPods to SwiftPM | Default since 3.44, May 2026 | Dependency manager, plugins degrade | Partial, plugin-dependent |
| Material and Cupertino out of SDK | Scheduled Nov 2026 stable | Formal deprecation, packages split out | dart fix --apply --code=migrate_design_widgets |
| KGP to built-in Kotlin | Flutter 3.44 | Hard build failure under AGP 9 | Documented manual migration |
| iOS and macOS minimum floors | Flutter 3.47 | iOS 13 to 15, macOS 10.15 to 12 | None; a product decision |
| UIScene lifecycle | iOS 27 SDK | App fails to launch if unadopted | None; required adoption |
Question 6: how are you handling the store deadlines?
Two dates bind every Flutter app this year, and only one of them is in the future.
Google Play's target API level policy states that "starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play", with Wear OS and Android Automotive at API 35 and Android TV and Android XR at API 34. The consequence of missing it is worth reading precisely, because it is routinely overstated: non-compliant apps "will stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app's target API level." Existing installs are unaffected, and an extension to 1 November 2026 can be requested.
Apple's requirement is already live. Apple's developer news post of 3 February 2026 set out that "starting April 28, 2026, apps and games uploaded to App Store Connect need to meet the following minimum requirements: iOS and iPadOS apps must be built with the iOS 26 & iPadOS 26 SDK or later", and Apple's submission guidance now states the same requirement in the past tense.
Flutter 3.47's defaults already put you at targetSdkVersion 36, so a current toolchain satisfies Google Play by construction. That is the actual argument for staying current: the deadline is free if you are up to date and a project if you are not.
Question 7: what evidence do you have, and what do you not have?
This is the question that separates an engineering partner from a sales one, and the honest answer disqualifies most Flutter marketing.
There is no credible, independently measured Flutter versus React Native benchmark in the public record. The startup-time and cost-reduction figures that circulate, including a widely repeated cold-start comparison, appear only in agency blogs with no traceable measurement behind them. If a partner quotes you a percentage for how much faster or cheaper Flutter is, ask for the source. There usually is not one.
The defensible evidence is narrower and more useful.
Adoption, from Google directly: the Flutter 3.44 release post from I/O 2026 states Flutter is "the second most popular development SDK for mobile on both major app stores with over 1.5 million monthly developers, a 50% increase in just one year", with over 1.3 billion package downloads in the preceding 30 days and more than 1,700 contributors landing 5,800 changes in the core repository over the year.
Survey position, from a neutral source: the Stack Overflow 2024 Developer Survey put Flutter at 9.4% and React Native at 8.4% among all respondents, and 9.4% against 9.0% among professional developers. That is the most recent Stack Overflow edition carrying the comparison; the 2025 survey did not publish one, so any Flutter percentage attributed to a 2025 Stack Overflow survey is mis-sourced.
A first-party migration account: LG Electronics wrote in its webOS Flutter experiment post that "without any optimization whatsoever, our Flutter rewrite launched twice as fast as our original app, consumed less runtime memory, and felt more responsive", and that Flutter gave them "increased developer productivity, better runtime app performance, and ... a smoother experience finding and hiring talented developers." The caveat belongs with the quote: LG was comparing Flutter to a React-based TV app, not to React Native on a phone, and the figure is LG's own.
If the decision is genuinely open between the two frameworks, the hiring market is usually the deciding variable rather than the runtime, which is the case we make in the React Native versus Flutter hiring decision framework and in our react native app development company page.
Governance: who actually maintains this now
Worth knowing before you commit a five-year product to it.
Canonical is now lead maintainer of Flutter Desktop. The 3.44 release post announced "an expanded partnership with Canonical, who will now serve as the lead maintainer and Strategic Steward for Flutter Desktop", leading the desktop roadmap and overseeing the Linux, Windows and macOS embedders.
Google is no longer the majority contributor. The Q2 2026 survey post states that "over 70% of currently open PRs in the Flutter project come from contributors outside of Google", and describes a proposed four-tier Contributor Ladder running Contributor, Reviewer, Committer, Maintainer, with public data-driven promotion in a new flutter/contributors repository, "replacing the old informal sponsorship model entirely."
Two related claims are circulating that we could not source to anything primary, so treat them as unfounded: there is no "Flutter Foundation", and 2026-dated claims about Google layoffs hitting the Flutter team trace to no primary source.
One nuance for Mac-based teams: Flutter's supported platforms page warns that "as Apple phases out Intel-based Macs, Flutter is phasing out support for Intel (x64) hardware", and the 3.47 post confirms automated test runs on Intel hardware are disabled with CLI warnings that "will become errors in a future release." No release number or date has been published for the removal. If a partner gives you one, they are guessing.
India-specific considerations
Two things shift the calculus for an India-based build.
Talent depth in Flutter is genuinely good and the rate differential is real, but the migration calendar above is where offshore engagements most often go wrong. A team hired on a fixed scope quoted before August 2026 has no contractual room for the November Material deprecation. Contract for a maintenance allowance tied to the four published stable releases rather than treating each one as a change request.
Second, if the app handles personal data of users in India, the Digital Personal Data Protection Rules commence in tranches with consent and notice duties landing 13 May 2027. That is an architecture decision to take during the build, not a compliance task afterwards. Our view is in the DPDP Act engineering playbook for Indian startups.
What we build, and how the engagement runs
eCorpIT builds Flutter applications for mobile and, where it fits, desktop, with the migration calendar written into the plan rather than discovered later. Our delivery process is discovery and platform-floor decisions, architecture and state-management selection, build in two-week increments with a running app from sprint two, hardening and security review under our ISO 27001:2022 practices, and launch with an agreed upgrade cadence covering the four stable releases a year.
We were founded in 2021, are based in Gurugram, and hold CMMI Level 5, MSME certification and ISO 27001:2022, with partner relationships including AWS, Microsoft and Google. On engagement models we run a fixed-scope build where the specification is settled and the delivery window sits clear of a known migration, a dedicated senior-led team on a monthly retainer where the roadmap is still moving, and a milestone-based build-and-transfer where you plan to take the code in-house. For a Q4 2026 delivery we will usually recommend against fixed scope, for the Material reason set out above, and we would rather say that up front than invoice for it later.
If you are assembling requirements, our mobile app development RFP template covers the questions above in a form you can send to several firms at once, and our Flutter 3.44 production upgrade guide shows the level of detail an upgrade actually involves. For a view on delivery models, see agency versus freelancer for mobile app builds.
FAQ
How eCorpIT can help
eCorpIT builds and maintains Flutter applications with the release calendar treated as a planning input rather than a surprise. We are a Gurugram-based technology company founded in 2021, holding CMMI Level 5, MSME certification and ISO 27001:2022, with senior-led engineering teams working across mobile, desktop and backend. If you are choosing between firms, the seven questions above work as a screening instrument whether or not you send them to us. If you would like us to review an existing Flutter codebase against the 2026 migration calendar before you commit to a rebuild, contact us and we will tell you what we find.
References
Last updated: 15 August 2026.
