settings_ui: native-looking settings screens for Flutter without hand drawing six of them

One API that draws six different settings screens

The claim in the package name is about platform coverage rather than widgets. `settings_ui` draws iOS 26 and Android 16 settings on phones, macOS System Settings, Windows 11 and GNOME on the desktop, and Chrome's settings page on the web, and it picks the style at runtime rather than asking the developer to branch on the platform. The implementation sits on top of `material_ui` and `cupertino_ui` rather than the Flutter SDK's own material library, and version 4.0.0 added a split view for iPad, tablets, foldables, desktop and the web, along with its own switch styling for iOS 26, which the documentation calls Liquid Glass. The target audience is a team that has one Flutter codebase shipping to several platforms and does not want to write and maintain a settings screen per platform.

The version fork follows your imports, not the release date

The most surprising thing about this package is that the major version you install is decided by your existing code. Version 4 needs Flutter 3.44 or newer and an app built on `material_ui` and `cupertino_ui`, imported as `import 'package:material_ui/material_ui.dart'` rather than `package:flutter/material.dart`. Apps still on the SDK's material library stay on `settings_ui: ^3.0.1`, and the documentation is explicit about not migrating the app unless you ask for it. If your code does import the newer packages, you have to add them to your own `pubspec.yaml` as well, since the package does not bring them along silently. The agent prompt spells the rule out in one line: package material or cupertino means `^4.0.0`, package:flutter/material.dart means `^3.0.1`. That is a blunt rule, and it means a large app on the older import path cannot move to 4.x without a migration it may not want.

Adding the dependency and the two UI packages

The install itself is one entry in your `pubspec.yaml`:

dependencies:
  settings_ui: ^4.0.0

If your app already imports `material_ui` and `cupertino_ui`, add those to your own manifest too, otherwise your build will fail to resolve the imports that `settings_ui` expects to find. That is the whole setup. There is no platform configuration, no native module to link and no code generation step, and the repository ships an `example/` application with directories for android, ios, linux, macos, web and windows, plus an `integration_test/` folder, which shows the package exercised across every platform it claims to support. The package is published to pub.dev as `settings_ui`, the repository is `yako-dev/flutter-settings-ui`, and the licence is Apache-2.0.

llms.txt is the recipe, and it is meant for an agent

The repository ships something unusual for a Flutter package: an `llms.txt` file at the top level, alongside `AGENTS.md` and `CLAUDE.md`, and a `doc/agent-prompts.md` with more prompts for upgrading from 3.x, replacing a hand built screen, adding a single setting end to end, adding a split view or auditing an existing screen. The short prompt in the README tells a coding agent to read the recipe section in `llms.txt` and follow it step by step, and to say so if it cannot open the link. The recipe itself is more interesting than a generated list of API names, because it encodes review rules: pick the version from the imports, show a plan and wait for approval before adding dependencies or screens, never invent URLs or email addresses, and ask the developer for them instead.

Tiles, destinations and the split view

The API surface follows the platform conventions the package is imitating. `SettingsTile.switchTile` handles on and off rows, `SettingsTile.navigation` handles rows that open a page or a picker, and a plain `SettingsTile` handles values and actions with no chevron. Sub-pages are attached to a navigation tile through `destination: SettingsDestination(id: ..., builder: ...)`, and the contract is that the builder returns only the body, because the package draws the header and the back button itself. That division is what keeps a custom sub-page looking native on each platform. Where the app runs on tablets, desktop or the web, `SettingsSplitView` puts the list and the page side by side instead of pushing a route. Section titles are asked to be in sentence case, which matches the Apple and Material conventions the recipe references.

The rows that decide whether an app passes review

The recipe spends a section on rows that look cosmetic but are not. Version and build number come from `package_info_plus`, and open source licences are shown with `showLicensePage`. Privacy policy, terms of use and contact support are opened with `url_launcher`, and the rule is to ask the developer for those URLs and email addresses rather than inventing them. If the app sells subscriptions or non-consumable purchases, a restore purchases row is expected. If users can create accounts, a sign out row and a delete account row are expected, where deletion starts in the app, asks for confirmation and calls the real backend, which the recipe ties to App Store Review Guideline 5.1.1(v) and notes that Google Play has a similar rule. Permission rows are also specified to show the real OS status and to open system settings when permission has been denied.

Testing a screen that has to look right everywhere

The verification steps in the recipe are unusually concrete, and they are the reason to read the file rather than skim it. Widget tests are asked to render the screen in the style of every platform the app ships, using `TargetPlatformVariant`, to confirm every toggle persists, and to confirm that links and actions fire. The split view is tested at two sizes, one pane at 402x874 and two panes at 1210x834, using `tester.view.physicalSize`. Then the same screen is checked on an iOS simulator and an Android emulator, plus iPad, desktop or web where relevant, in both light and dark mode, with the appearance switched through `xcrun simctl ui booted appearance dark` and `adb shell cmd uimode night yes` and screenshots taken with `xcrun simctl io booted screenshot` and `adb exec-out screencap -p`. If no device can be launched, the expectation is that the agent says what to run instead.

Editorial conclusion

Adopt settings_ui if you are shipping a Flutter app to more than one platform and do not want to hand build a settings screen per platform, since the value of the package is exactly that single API. Do not adopt it if your app still imports `package:flutter/material.dart`, because that combination means staying on the 3.x line rather than the 4.x line you want. Verify first that the app runs on Flutter 3.44 or newer and that `material_ui` and `cupertino_ui` are added to your own `pubspec.yaml`, and settle the delete-account and privacy-policy rows before submission because those are the rows store review actually checks.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. yako-dev/flutter-settings-ui on GitHub