The Flutter team published its Q2 2026 user survey results, and the headline number is not the interesting part. Overall satisfaction sits at 93 percent, essentially unchanged. What moved is the intensity behind it, and what the survey reveals about where developers place their trust.
Over 3,500 developers responded to the survey, which ran from 8 to 22 June, recruited through the Flutter IDE plugins for VS Code, IntelliJ, and Android Studio, plus X and the Flutter website.
Satisfaction did not rise. Conviction did.
The top-line 93 percent held steady from Q4 2025. Underneath it, “very satisfied” climbed from 52 to 58 percent, a statistically significant six-point move, while “somewhat satisfied” fell from 40 to 35 percent. People are not arriving at Flutter in greater numbers of approval; the people already there are more convinced.
Trust that Flutter will consistently meet development needs rose from 77 to 83 percent over the same period.
For the first time in the survey’s history, every measured subgroup – by experience level, company size, team size, and platform – came in at 90 percent or above. The strongest individual areas were the Dart language at 92 percent, Android app development at 91, and the core framework at 90.
Novice developers, historically the least satisfied group, reached 90 percent, up five points. The team credits the guided Getting Started pathway launched in February.
But there is a caveat worth sitting with. Isolate the core framework for that same novice group and satisfaction drops to 82 percent, against 93 for experts. That eleven-point spread is wider than almost any other split in the survey. Onboarding got better; the framework itself is still steep. The team says so plainly, and notes that novices also report lower AI tool adoption, which may be part of the gap.
Claude Code and Antigravity have overtaken the incumbents
This is the first cycle where the survey asked about editors and coding agents, and the result is sharper than most people would guess.
VS Code still leads at 66 percent, with Android Studio at 40. Directly behind them:
- Claude Code – 32%
- Antigravity – 23%
- GitHub Copilot – 19%
- Cursor – 18%
- Codex – 17%
Agent-first tools have passed the assistant-in-your-IDE generation among Flutter developers. Respondents could select multiple tools, so these do not sum to 100, but the ordering is what matters.
Satisfaction with the tools clusters high – VS Code at 88 percent, Claude Code at 86, Codex at 85. One outlier stands out: Zed at 38 percent, far below everything else, though usage is only 5 percent.
Cupertino is the weak point, and the team knows why
Cupertino widgets fell six points to 61 percent, the steepest decline anywhere in the survey and now the lowest-rated area in Flutter.
Developers reported that Flutter’s promise of native-feeling apps had not kept pace for iOS-style design, with some suggesting native design systems were deprioritised once they became hard to maintain inside the core framework.
The team’s answer is that the drop was expected. Work on Cupertino widgets was deliberately paused to execute the decoupling of Material and Cupertino from the framework – the same change that shipped as a code freeze in Flutter 3.44.
Web at 72 percent, Linux at 73, and Windows at 74 remain the other soft spots, though all three improved from Q4 2025. The roadmap items meant to lift them – making WebAssembly the default web target, and expanding multi-window desktop support with Canonical – are still ahead, which is why the gap has not closed yet.
Where the decoupling actually stands
Both material_ui and cupertino_ui now exist on pub.dev under the verified flutter.dev publisher, at version 0.0.3+1, published on 11 and 10 August respectively.
They are not usable yet. Both are marked unlisted, and both READMEs open with “Coming soon” and describe the migration in future tense. What has landed is the namespace and the scaffolding, not the libraries. The Flutter team is tracking the work on a public decoupling project board.
This matters for planning. The packages existing is not the same as being able to migrate to them, and anyone reading “shipping in the August release” should treat that as the start of the process rather than the end. Once the migration completes, native design fidelity stops being gated on core framework release cycles – which is what unlocks the Material 3 Expressive and Apple Liquid Glass work the team has flagged, on the Material and Cupertino sides respectively.
Developers trust Flutter more than they trust Google
The survey added a trust section this cycle, and it produced the most quotable finding in the report.
Asked to rate trust in Flutter and trust in Google separately, respondents put Flutter more than 20 points ahead every time: 83 percent versus 62 percent, consistent across every company size. Awareness is not the explanation – 98 percent correctly identified Google as Flutter’s creator.
Asked what builds that trust, framework performance and stability led at 26 percent, ahead of community size and activity at 20 and documentation quality at 19. And when evaluating a brand-new feature, 41 percent said they would trust it because the community had battle-tested it, against 26 percent who would trust it because Google engineers built it.
The team reads this as support for widening the maintainer base beyond Google, which is a candid interpretation of a result that could have been framed less comfortably.
What developers said is broken
Four themes drove dissatisfaction:
- Platform and ecosystem maturity (44%) – the largest theme, and specifically about upgrade pain rather than getting started. Developers described losing hours to version-matrix guesswork on Android, juggling Flutter, Dart, Gradle, Kotlin, and JVM versions at once.
- Tooling and IDE experience (33%) – centred on wanting deeper Android Studio integration: more AI tooling, more native support, better visualization.
- Bugs and stability (24%) – pointed at debug tooling, including breakpoints that persist after removal and a confusing performance timeline. The team states directly that there is no shipped fix.
- UI/UX aesthetics (14%) – the smallest theme, but the one tied to Cupertino’s decline.
On the Android upgrade pain, the team laid out a multi-release response: Flutter 3.29 removed legacy script-based Gradle plugin application, 3.32 rewrote the Gradle plugin from Groovy to Kotlin, 3.38 published an official version matrix across Java, Kotlin, AGP, and Gradle, 3.41 added AGP 9 support, and 3.44 shipped the migration to built-in Kotlin.
One number from the SwiftPM transition also stands out: 92 of the top 100 iOS plugins have already migrated away from CocoaPods.
A formal contributor ladder
Agreement that Flutter is proactive about technical issues and responsive to developer feedback sits at 71 percent – more than 10 points below every other statement the survey asked about reliability and safety.
Part of the structural answer arrived after the survey closed. The team published a proposal for a four-tier Contributor Ladder – Contributor, Reviewer, Committer, Maintainer – with public, data-driven promotion tracked in a new flutter/contributors repository. It replaces the informal flutter-hackers group, where a trusted role carrying code review rights and merge access was decided case by case by whoever happened to notice your work. It also introduces a formal path to project leadership, not just code contributions.
Over 70 percent of currently open PRs in the Flutter project come from contributors outside Google. Combined with Canonical taking the desktop roadmap, the direction is consistent: Flutter is being restructured so that Google is one maintainer among several rather than the gatekeeper.
The read
Two findings are worth carrying forward. Agentic coding tools are now mainstream in Flutter development rather than experimental, and the ordering favours agent-first tools over IDE assistants. And developers have separated their confidence in Flutter from their confidence in its owner, which is unusual for a corporate-backed open source project and explains why so much of the 2026 roadmap is about governance rather than features.
The full results are on the Flutter blog.
Leave a Reply