Cupertino Widgets Hit 61% Satisfaction: Flutter's Lowest-Rated Area

In Flutter’s Q2 2026 user survey, Cupertino widgets scored 61% top-2 box satisfaction — down 6 points from Q4 2025, the steepest decline anywhere in the survey, and the lowest-rated area measured. Dart language sat at 92%, Android app development at 91%, the core framework at 90%. Cupertino was alone at the bottom, and the drop is what dragged the “UI/UX aesthetics” dissatisfaction theme into the results at 14%.

If you ship an iOS-styled Flutter app, this section of the survey is about your roadmap. Here’s what the numbers say, why the team says it happened, and what’s changing.

What developers actually said

The team reports the qualitative feedback behind the 61% came down to one complaint: developers feel Flutter’s promise of native-feeling apps hasn’t kept pace specifically for iOS-style design. The sharpest version of that concern is about priority — that native design systems got deprioritized once they became difficult to maintain inside the core framework. A design system that ships once per Flutter release cycle can’t track Apple’s; every WWDC potentially widens the fidelity gap between your Flutter app and the platform around it.

The team’s response doesn’t dispute the score: “this doesn’t come as a surprise. We intentionally paused work on Cupertino widgets to execute on decoupling to get to that better world where we can ship faster.”

The root cause: design systems trapped in the core release train

The structural problem predates this survey. Material and Cupertino have been migrating out of the core Flutter framework into standalone packages for some time (tracked in issue #101479), with the argument that decoupling unlocks faster design releases, independent upgrades, and faster reactions to platform shifts — Apple’s Liquid Glass and Material 3 Expressive being the named examples. But decoupling takes work, and Cupertino was the team’s explicit sacrifice: work paused during the transition, satisfaction paid the price in the interim.

The Q2 survey announced the remedy: publishing material_ui and cupertino_ui on pub.dev as the first step of decoupling. That has since landed. cupertino_ui — “the official Flutter Cupertino Design Library, implementing the iOS design system” — is live on pub.dev under the flutter.dev verified publisher, BSD-3-Clause, supporting Android, iOS, Linux, macOS, web, and Windows. Its stated scope covers the full iOS toolkit: CupertinoApp, CupertinoPageScaffold, CupertinoTabScaffold, navigation bars (including sliver variants), CupertinoButton, segmented controls, CupertinoTextField and form sections, pickers and date/time dialogs, action sheets, CupertinoListSection/CupertinoListTile, theming, and CupertinoLocalizations.

What decoupling changes for your app

Once native design fidelity is versioned separately from the SDK, it stops being gated behind core framework release cycles and can iterate on its own schedule — the team explicitly says this foundational work is already unblocking platform-fidelity work it “couldn’t move fast enough on before,” naming Material 3 Expressive and Apple’s Liquid Glass. For your iOS-styled app, that means Cupertino fixes and fidelity improvements can ship between Flutter releases, and contributions to the design system can land faster.

For existing code, migration is scripted. The packages ship a data-driven Dart fix:

# Adds cupertino_ui and rewrites imports automatically.
dart fix --apply --code=migrate_design_widgets

That performs the equivalent of adding the package and changing package:flutter/cupertino.dart imports to package:cupertino_ui/cupertino_ui.dart. Two follow-ups matter:

1. Localizations. Don’t use GlobalMaterialLocalizations or GlobalCupertinoLocalizations from flutter_localizations; use the new versions from material_ui and cupertino_ui respectively.
2. Legacy dependencies. If third-party packages still import package:flutter/cupertino.dart, bridge them rather than forking them.

import 'package:cupertino_ui/cupertino_ui.dart';

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return CupertinoApp(
      builder: (BuildContext context, Widget? child) {
        // Lets legacy Cupertino widgets resolve inside modern trees.
        return CupertinoUiCompatibilityBridge(child: child!);
      },
      home: const HomeScreen(),
    );
  }
}

CupertinoUiCompatibilityBridge (and its Material twin, MaterialUiCompatibilityBridge) bridges theme data and localizations so legacy widgets resolve correctly in the new widget trees — you can also wrap individual subtrees containing legacy package widgets instead of the whole app. One installation note: the pub.dev instructions use flutter add cupertino_ui, mirroring the new add-command workflow for the design packages.

How much of the problem this actually fixes

Be precise about the bet here. The 61% measured dissatisfaction with current fidelity; the decoupling response is a process fix — faster iteration, not an instant widget drop. The survey text is careful: the packages are a foundational step that unblocks fidelity work, with Liquid Glass and Material 3 Expressive adoption ahead of it. If your complaint was “Cupertino feels stale compared to the latest iOS,” the improvement comes from a design system that can now ship on its own cadence — but the fidelity work itself is the next chapter, not this one.

Context helps too: the same survey shows web (72%), Linux (73%), and Windows (74%) all improved against Q4 2025, and overall satisfaction held at 93% with trust in Flutter at 83%. Cupertino’s decline is an outlier in an otherwise rising survey — which is likely why the team was willing to publish it so bluntly and pair it with the decoupling announcement rather than bury it.

What to do now

If you maintain an iOS-styled Flutter app, the practical sequence: run the migrate_design_widgets Dart fix on a branch, wire up CupertinoUiCompatibilityBridge for any third-party Cupertino dependencies, move localization delegates to the package versions, then track the cupertino_ui changelog independently of your Flutter SDK upgrade cadence. That last part is the whole point — for the first time, keeping your app’s iOS fidelity current no longer waits on a framework release.

Sources

• Flutter Q2 2026 survey — trust, transparency, and an evolving community
• cupertino_ui on pub.dev
• material_ui on pub.dev
• Material and Cupertino decoupling tracking issue
• Material and Cupertino decoupling are here (Flutter blog)