In Flutter 3.47, what is the cupertino_ui package, and how does it relate to package:flutter/cupertino.dart?

## Why the Cupertino library moved For most of Flutter's history the design libraries lived inside the framework: `package:flutter/material.dart` and `package:flutter/cupertino.dart` shipped with each SDK. That coupling had costs: - Widget fixes and new components waited for quarterly SDK releases. - Apps could not upgrade the design library without upgrading the engine and framework. - The core framework carried two opinionated design systems, making style-neutral custom design systems harder. The Flutter team's answer is to publish the design systems as ordinary pub packages: **`material_ui`** and **`cupertino_ui`**, maintained in the `flutter/packages` repository. ## The timeline that matters 1. **Flutter 3.44** — contributions to the in-SDK `material.dart` and `cupertino.dart` libraries were **frozen**. 2. **Flutter 3.47** — version 1.0 of `cupertino_ui` and `material_ui` is published on pub.dev. The 1.0.0 code **matches the frozen framework code**, so switching changes no behaviour at that point. 3. **After 1.0** — the packages release on their own schedule (the plan is weekly) with semantic versioning. 4. **A later stable** — the in-framework libraries are scheduled for formal deprecation. In 3.47, opting in is optional. At the time of Flutter 3.47.5, `cupertino_ui` is at **1.1.1**, whose pubspec requires `flutter: ">=3.47.0"` and Dart `^3.13.0`. Its 1.1.0 release already contains changes that the frozen SDK library does not, such as allowing a `CupertinoTabBar` with a single item and an option for `CupertinoPageRoute` and `CupertinoPage` to opt out of introducing a semantics route scope. ## What changes for your code | Aspect | `package:flutter/cupertino.dart` | `package:cupertino_ui/cupertino_ui.dart` | |---|---|---| | Where it comes from | The Flutter SDK | pub.dev, declared in `pubspec.yaml` | | Receives fixes | No, frozen since 3.44 | Yes, independent releases | | Versioning | Tied to the SDK version | Semantic versioning | | Widget names | `CupertinoApp`, `CupertinoButton`, ... | Same names and APIs at 1.0 | The widget API is the same at 1.0: `CupertinoApp`, `CupertinoPageScaffold`, `CupertinoNavigationBar`, `CupertinoButton` and the rest keep their names. What changes is the import and where updates come from. The mechanical migration (a `dart fix` rule, the compatibility bridge for dependencies that still import the SDK library, and localization classes) is a separate topic. ## Dependencies between the two packages `material_ui` lists `cupertino_ui` as a dependency, because Material's adaptive constructors (`Switch.adaptive`, `Slider.adaptive`, `CircularProgressIndicator.adaptive` and others) render Cupertino widgets on iOS and macOS. So: - A Material app that adopts `material_ui` gets `cupertino_ui` transitively. - A pure Cupertino app can depend on `cupertino_ui` alone. - An app should not mix the SDK import and the package import of the same library in its own code, because the classes are distinct types even when their names match. ## What stays in the core framework The move affects only the two design libraries. The core widgets layer (`package:flutter/widgets.dart`), rendering, painting, gestures, animation and services stay in the SDK and keep shipping with Flutter releases. Widgets such as `Navigator`, `ListView`, `SafeArea` or `MediaQuery` are therefore unaffected, and a custom design system built only on `widgets.dart` needs neither package. This split is exactly the "style-neutral core" the Flutter team describes: the SDK provides the building blocks, and each design language becomes a package that can move at its own pace. ## How to explain it in an interview - **What:** the Cupertino widget library as a standalone, semver-versioned package. - **Why:** faster fixes, independent upgrades and a style-neutral core. - **Status in 3.47:** available and recommended for new work, optional, with the SDK copy frozen but not yet deprecated. - **Risk:** during the transition, third-party packages may still import the SDK library, which is why a bridge exists. ## Common misunderstandings - Thinking `cupertino_ui` is a community package or a fork; it is the official library, published by the Flutter team. - Believing the SDK's `cupertino.dart` still receives fixes after 3.44. - Assuming the widget names changed; at 1.0 the API matched the framework. - Expecting `cupertino_ui` to wrap native UIKit controls; it is the same Flutter-drawn library, only packaged differently.