Mobile UI reference

Flutter-first, code-first. Gather shipped screens, write a spec, build the UI, then park screenshots in Figma as a reference board. Figma is not the source of truth until a human must approve mocks before code.

Do not start with ui-ux-pro-max --design-system (landing-page palettes). Do not prompt "generate a paywall." Split turns: research note, then implement. At commit d14efff8 (2026-10-23) its SKILL.md marks --design-system as required for new pages and projects and builds the result from product, style, color, landing and typography tables, so it suits web and landing pages. Its Flutter and SwiftUI entries are stack-guideline tables whose first rows are generic code rules (for example "Use StatelessWidget when possible" and "Use struct for views"), not screen design direction. Treat it as a web-first source, and keep references from shipped screens as the starting point for a Flutter screen.

0. Name the job

One sentence. Feature + job to be done. Example: "Hard-paywall after onboarding quiz, annual default, skip control visible."

Platform default: iPhone-first Flutter (Cupertino + HIG) unless the product is branded (Forui / own tokens) or Android-first (Material 3).

Name the target stack and the repo's existing conventions in the first message. If the agent has to ask for the stack, the brief is incomplete. Add the audience, three liked apps and one image of the target feel to the one-sentence job. The three liked apps seed the same-category picks in step 1 and the image sets the feel for the critique, and neither replaces the references. The source for both rules is one practitioner's thread, not tested here.

1. Gather 5–8 shipped references

Research, not generate. Stop at 8. Critique exists before any Dart.

Preferred (paid Mobbin MCP, Pro/Team/Enterprise): https://api.mobbin.com/mcp. Tools: search_screens, search_flows, search_sections (web sections). Empty tool errors usually mean unpaid, so fall back and don't invent patterns.

Mix:

• 2 named apps in the same category
• 2 category hits ("iOS onboarding productivity")
• 1 adjacent category (so you do not clone one brand)
• 1 anti-example you will not copy

Stay in research mode: "Show 6 iOS onboarding flows that ask for notification permission after value, not before. Describe structure, do not generate UI."

Other reference sources (checked 2026-10-13, prices from live pages):

The Refero, Gummble and ScreensDesign terms ban scraping, systematic retrieval or building a competing dataset, and only Gummble names bulk download, per the vendor's terms page, read 2026-10-17, not verbatim. Page Flows lists "Batch download screens" as a plan feature, and its terms contain no bulk download or dataset clause, per the vendor's terms page, read 2026-10-17, not verbatim. Keep each pull to the 5 to 8 references this step needs. Revyl's terms restrict redistribution and sublicensing of its services, so read Atlas maps in the browser and never copy its screenshots into a repository. 60fps terms (read 2026-10-23, summary not verbatim) allow use for your own work and products, bar reading the library with scripts or crawlers outside an AI tool, and bar using it to train or evaluate a model. Generated motion code is the user's, and the recorded apps' brands and assets are not, so rebuild the motion and never copy an app's assets. Its skills install command and any MCP connection are remote code and go through the code-gate rule before use, and nothing here proposes installing them. Native Cook's terms (read 2026-11-04) license a copied prompt and what is built from it for your own projects, and bar redistributing its prompts or videos, scraping or bulk copying, and building a competing catalog. Read it in the browser, copy one prompt at a time, and never save its videos or prompts into a repository. The author says an agent built one block from its prompt in 11 minutes in the iOS Simulator with the run sped up (a single report), and its FAQ says output is only "usually close", so review the result against the video and read the generated dependencies and their licenses, as its terms require.

No Mobbin: screenshot 3–5 apps on a device. Save under design-refs/<feature>/. Paywalls: https://toomanypaywalls.com for pattern labels, not chrome.

For an onboarding or paywall job, also walk at least one reference end to end on a device, because a gallery shows screens and not what each answer or exit does. Record per screen the exact copy, where an earlier answer reappears, where the account and the paywall sit, and what closing the paywall does. Paywall conversion flow lists what one such walk found and the checklist for it.

1b. Concept, then three directions

References show structure. They do not give the app a face. Before any screen, name one real-world object or place the app is, such as a running app as an athletics track, a sleep app as a village going to sleep, or a plant app as paper cut-outs. Let that concept set type, palette, illustration style and motion. "Clean", "minimal", "modern" and "premium" are not directions. Sketch the main screen three ways from the concept, pick one with the human, then build every other screen from the chosen one. The method is Tobia Donadon's free "How to Stop Making your Apps Look Like AI Slop" article (October 2026). His paid skill, App Designer Pro, packages it.

1c. Duo concept pass

Use this when the app will ship to iPhone Duo. Before changing code, draw each key screen twice, once for the outer display and once for the open inner display. Decide which content moves to a second pane and which stays in the first. Pairs reported by one author: a music app puts artwork on one pane and controls on the other, a productivity app puts the workspace beside a tool panel, a finance app puts the balance and primary actions on one pane and "safe to spend" plus upcoming items on the other. Name the one thing the inner screen shows that the outer screen cannot, because the same capture is needed for the Duo screenshot deck. Then hand layout work to the framework skill, such as swiftui-pro and its references/resizability.md. Source: Tobia Donadon, October 2026, a skill demo with no public code, so treat the pairs as examples and not as tested patterns. Evidence level: demo video and author text only, the skill and its output were not seen.

2. Critique

Fail-closed iPhone-first checks:

• Type: HIG sizes (~34pt large title, 17pt body, 13pt footnote). Fail: Roboto / Material 3 defaults on iOS
• Shape: superellipse, cornerSmoothing ≥ 0.6. Fail: BorderRadius.circular everywhere
• Press: opacity, no Material ink. Fail: splash/ripple
• Color: one seed → shade ramp. Fail: unrelated accent per screen
• Touch: 44pt min, 8pt+ gap
• Safe area: home indicator, notch, keyboard
• Compact chrome: concentric inner shapes; no empty "forehead"
• A11y: 4.5:1 light and dark, label not icon-only, Reduce Motion via MediaQuery.disableAnimationsOf(context)
• Motion: Flutter springs for layout; Rive only for a state-machine/character
• Timed motion (not a spring): under 300 ms with an ease-out curve, never Curves.easeIn on an entrance. Curves.easeOut is the CSS ease-out (Cubic 0, 0, 0.58, 1) and Curves.easeOutQuint is Cubic(0.23, 1, 0.32, 1), the stronger curve the web guidance uses. Fail: Curves.easeIn or Curves.linear on a menu, sheet or toast, and any hand-typed Cubic that differs from the app's motion tokens.

Paywall/onboarding: warm ask after a win. Soft = visible skip. Hard = after commitment. No close button is a dark pattern. Trial: timeline before price. Permissions after value. Duolingo's 19–38 quiz screens are a habit game, not a utility template.

IAP wiring belongs in Flutter paywall and review timing.

Live Activity / Dynamic Island (only if the feature is compact chrome): concentric margins, compact snug to the sensor, expanded hugs the sensor, minimal still shows data. Flutter cannot host the island.

3. Apply in Flutter first

UI only. Fake data. No RevenueCat, no repository, no FutureBuilder.

1. Prefer CupertinoApp / CupertinoPageScaffold / CupertinoListSection / CupertinoButton. Import package:flutter/widgets.dart + package:cupertino_ui/cupertino_ui.dart (Flutter 3.47+, add with flutter pub add cupertino_ui). Material and Cupertino now ship as standalone material_ui / cupertino_ui packages, and the package:flutter/material.dart / cupertino.dart imports are slated for deprecation, so stop treating material.dart as the framework. If the app is already MaterialApp, still do not add ink splash on new screens.
2. Superellipse, not BorderRadius.circular:

import 'package:figma_squircle/figma_squircle.dart';

decoration: ShapeDecoration(
  color: const Color(0xFFFFFFFF),
  shape: SmoothRectangleBorder(
    borderRadius: SmoothBorderRadius(
      cornerRadius: 20,
      cornerSmoothing: 1,
    ),
  ),
)

Clip children with ClipSmoothRect.

1. Kill Material splash. No InkWell / default ElevatedButton splash. Use a GestureDetector + opacity dip (<150ms). Disabled = opacity ~0.4, not a grey box. Hit area ≥ 44×44. SafeArea on headers, tab bars, bottom CTAs.
2. Rive vs Flutter:

Rive files play through the official rive package (0.14.11 on pub.dev, checked 2026-10-13). Lottie files play through lottie (3.6.1), a third-party package by xvrh, not an official Airbnb release. Use Lottie for a one-shot or looping illustration with no inputs, and Rive when the animation reacts to app state through a state machine. Rive's free plan exports with a splash screen, so a shipped .riv needs a paid seat. Lottielab exports Lottie JSON only on a paid plan, and Jitter's free tier exports at 720p 30fps with a watermark.

Never Rive a page route. liquid_glass_renderer is 0.2.0-dev, Impeller-only, 16-shape cap — not a layout system. Never on Web/Skia.

3b. Status bar over imagery

Flutter has no equivalent of the package below in the source that raised this. If a Flutter screen needs an adaptive status bar, port the spec of @rbayuokt/expo-adaptive-status-bar (author's reply and diagram, October 2026). Sample the left and right 35% strip, use linear luminance, switch to dark icons above 0.58, white icons below 0.42, and keep the current style in between. Require two agreeing readings near a threshold and enforce at least 250 ms between switches. Apply the result with SystemChrome.setSystemUIOverlayStyle. The Flutter port is our inference. The thresholds are the author's, and no source shows they are tuned. No Flutter source was read.

4. Drop running UI into Figma

1. iPhone simulator. Capture UI-only, plus one with chrome if island/home-indicator context matters.
2. Figma page Refs / <feature>. Place PNGs as reference frames. Do not rebuild from components first.
3. Slice only repeating pieces (row, chip, CTA) if a second screen will reuse them.
4. Do not use web-only Figma generate-design capture. Do not round-trip through Figma SwiftUI. Do not run Specs Classic (deprecated).

If later you want production Figma components linked to Flutter, that is a different installed Figma skill.

4b. Optional: a human designs the base in Figma

Use this second flow only when a person owns the visual style and will design in Figma. It does not change the stance above, because the style comes from a human and not from model-generated UI.

1. The person designs only a few key screens in Figma, which fixes the type scale, spacing, colour and components.
2. The agent reads them through the Figma MCP, with the target stack named in the first message, and builds the remaining screens from the step 1 references in that style, with the critique in step 2 still written before any Dart.
3. The person still designs the paywall and any screen with unusual mechanics.

The Figma MCP can read and edit the canvas but cannot read comments, so use figma-review-loop for comment review. The source is one practitioner's thread, and no result from that process was verified.

5. Pre-delivery

• No emoji as icons
• Contrast ≥ 4.5:1 light and dark
• List content not hidden behind the CTA
• Reduced motion: skip Rive / glass stretch
• Dynamic Type: titles wrap, CTAs don't clip
• Pressed state does not shift layout bounds

Render the built screens on the simulator at device resolution, then run a separate critic pass that fails any of these AI tells:

• Purple or blue gradient hero card
• Emoji standing in for illustration or icons
• Repeated identical cards with uniform padding
• Demo numbers that repeat across rows or do not add up to the stated total
• A verdict word or praise label on a metric that the number does not support ("Excellent!" on a 64% recovery score, "Healthy heart!" on any heart rate), or a verdict with no stated threshold
• A change figure that the same screen's history contradicts (an up 10% chip next to a week row that falls from 68 to 64)
• Plain avatar circle and a generic title such as "My Savings Goals"
• Gradients with no job
• Body-text sentences where a concrete number or object would do ("€49 to go", "€49 is three takeaways")
• A screen that is tidy but could belong to any app

Before the critic scores a direction, run break-ui on its main screen with real-length labels, the largest text size, an empty state, a failed payment or limit-reached state and long or malformed numbers. A direction that only looks distinct with demo data fails. Format every amount through the locale formatter, never by hand ("€1,2500" is the tell).

Give every screen a word budget before writing copy. No em dashes or AI stock phrases in UI strings. That covers slogans ("Unlock your potential", "Seamless. Effortless. Powerful.") and in-app encouragement filler ("Good progress! Keep it up.", "Take a moment to be proud.", "A calmer, brighter you", "Small steps. A brighter tomorrow.", "That's 12 more than last week!"). Replace them with the fact the line is about, or delete them. Name the user's object, not the category. One demo rewrote "My Savings Goals" to "Saving for", "Add Money" to "Put in", "+€1.85 saved!" to "+€1.85 to the bike" and "Target date: Oct 26" to "yours by 26 Oct", and set section titles in sentence case ("Next closest"). Read every string that holds a number at 0, 1 and many, and check the verb and noun agree with what is counted ("61% of your limits are in use", "1 thing to do", "3 steps to take"). Show where a graded number comes from: the baseline, the window and the sync time ("TODAY · 14D AVG 71", "SYNCED 07:12" in one health-app demo, video frames read 2026-10-30). Use a verdict word only when the app has a stated threshold for it, and otherwise show the number and its baseline and let the person judge. That threshold rule is an inference from two replies and the demo author's own answer, not a documented standard. For a health or fitness metric, check App Review guideline 1.4.1 before shipping any word that reads as a diagnosis or a medical claim. Whether 1.4.1 applies to a fitness recovery score is not established, so this is a check and not a finding.

Paste the spec + 2–3 reference links before asking a model to write widgets.

Sources

• https://mobbin.com/mcp
• https://mobbin.com/blog/how-to-use-mobbin-mcp
• https://toomanypaywalls.com
• https://docs.flutter.dev/ui/widgets/cupertino
• https://pub.dev/packages/figma_squircle
• https://developer.apple.com/videos/play/wwdc2023/10194/
• https://docs.flutter.dev/release/breaking-changes/material-ui-and-cupertino-ui
• https://pub.dev/packages/liquid_glass_renderer
• https://developer.apple.com/design/human-interface-guidelines/typography
• https://developer.apple.com/design/human-interface-guidelines/accessibility
• https://api.flutter.dev/flutter/widgets/MediaQuery/disableAnimationsOf.html
• https://x.com/tobiadonadon_/status/2106430529113301163 (Tobia Donadon, "How to Stop Making your Apps Look Like AI Slop", article 2106428717639626752, concept-first method)
• https://x.com/tobiadonadon_/status/2112305196001018212 (Tobia Donadon, Duo Designer skill demo and "Get Your App Ready for the iPhone Duo", October 2026, no public code, unverified)
• https://x.com/rbayuokt/status/2112217296500654256 (rbayuokt, adaptive status bar spec, October 2026, README and npm read, benchmark self-reported)
• https://x.com/breejeanadkat/status/2111411956599149046 (stack named first, brief inputs, human-designed Figma key screens, practitioner thread, unverified)