For an iOS-first Flutter wine-cellar app that must feel native on iPhone and also ship on Android, how do you choose between one brand look and platform-adaptive UI?

## The premise Unlike toolkits that wrap platform controls, Flutter paints every pixel itself. A `MaterialApp` looks like Material on an iPhone, and a `CupertinoApp` looks like iOS on Android. So "feel native on iPhone" is something you build, and every bit of platform adaptation is code you own. The judgement is how much to adapt. ## The spectrum of options | Strategy | What it looks like | Cost | Fits when | |---|---|---|---| | One brand look | `MaterialApp` or a custom design system everywhere | Lowest: one tree | Strong brand, content-led app, small team | | Brand look plus adaptive controls | Shared screens, `.adaptive` controls, adaptive dialogs, a few platform-aware widgets | Moderate | Most apps that want to feel at home on iOS | | Platform shells | `CupertinoApp` shell on iOS, `MaterialApp` on Android, shared inner screens | High | iOS-first products where the shell must be indistinguishable from native | | Fully separate UIs | Two widget trees per screen | Very high | Rarely justified in Flutter | ## What iPhone users actually notice Research the list before choosing, because it is shorter than it looks: - **Navigation:** the edge back-swipe, the navigation bar with a back label, large titles, tab bar placement. - **Controls:** switches, sliders, date and time pickers, segmented controls. - **Modal UI:** alert dialogs and action sheets. - **Feel:** scroll physics and overscroll, text selection handles, haptics. - **Typography and icons:** the system font and SF-style icons. Flutter already adapts some of these by platform (scroll physics, text selection controls, the default page transition on iOS), and Material's `.adaptive` constructors cover switches, sliders, checkboxes, progress indicators and dialogs. What remains is usually small. ## A recommendation for the wine-cellar app For an iOS-first app that also ships on Android: 1. **Keep brand surfaces shared.** Bottle cards, tasting notes, the cellar map and charts are the product's identity; they should look the same on both platforms. 2. **Adapt the controls.** Use `Switch.adaptive`, `Slider.adaptive`, `CircularProgressIndicator.adaptive` and `showAdaptiveDialog` by default. 3. **Adapt the shell only where it pays.** A small set of platform-aware widgets (an app bar, a date picker launcher, an action sheet helper) that switch on `Theme.of(context).platform` gives iPhone users the bar and sheets they expect without duplicating screens. 4. **Reserve full `CupertinoApp` shells** for a brief that explicitly requires indistinguishable-from-native navigation, and accept the cost of maintaining two app roots. ## Costs that decide it - **Design cost:** every adaptive surface needs two designs, and designers must review both. - **Test cost:** each adaptive widget doubles golden images. Setting `ThemeData(platform: TargetPlatform.iOS)` lets one CI host render both, but the images still need review. - **Library cost:** since Flutter 3.47, Cupertino is also shipped as the standalone `cupertino_ui` package on its own release cadence, one more dependency to keep current. - **Consistency cost:** a platform-aware widget layer must be the only place that branches; scattered `if (isIOS)` checks rot quickly. - **Team cost:** people must know two widget vocabularies; a small team may not sustain that. ## Signals for each direction Choose **one look** when the brand is the product, the user base is split evenly, or the team is small. Choose **more adaptation** when iOS users are the majority, reviews mention the app feeling foreign, or the app sits next to system apps users compare it with (settings-like screens, forms full of toggles and pickers). ## A staged plan 1. **Ship one look with adaptive controls** first, since it is cheap and covers the most visible differences. 2. **Measure:** app-store reviews, support tickets and usability sessions with iPhone users tell you whether anything still feels foreign. 3. **Adapt the shell** (bar, sheets, pickers) through platform-aware widgets if the evidence says so. 4. **Only then consider separate app roots,** with a clear owner for each and a budget for the duplicated testing. ## Guardrails whichever way you go - One module owns platform branching; widgets ask it, never `Platform.isIOS`. - Golden tests render key screens for iOS and Android. - Accessibility is checked on both paths, since some adaptive parameters (such as a progress indicator's `semanticsLabel`) are ignored on Apple platforms. - Revisit the decision when analytics or reviews change, not when a designer prefers a new style. There is no single right answer; the principal-level answer is the reasoning, the cost model and a staged plan that starts with adaptive controls and grows only where evidence says it should.