iOS Design Prompt

先点名三个已上架 App 作为参照标杆，再守住细节底线：4pt 栅格、Text Styles、语义色、44pt 触控目标、精确到名字的 SF Symbols、带时长的动效。

设计前必须先点名三个在这件事上做得漂亮的已上架 iOS App，并说出各自好在哪个具体细节；说明本屏最重要的那一个动作；说明真实使用场景。随后的细节底线覆盖布局、字体、颜色、触控、图标、动效与触感反馈，禁止一切含糊取值——间距精确到 pt、自定义色必须给出深色变体与对比度数值、每个转场都要有时长与曲线并在 Reduce Motion 下有降级方案。最后是完整状态清单，以及一轮「哪里像网页」的自我批评。

# iOS Design

**Use when:** you ask an agent to design a screen, a component, or a flow for iOS and you want something that looks like Apple shipped it.
**Pairs with:** [swiftui.md](swiftui.md), [../design/ui_design.md](../design/ui_design.md), [../core/loop_engineering.md](../core/loop_engineering.md)

This is the prompt for the exact problem of "I asked for a button and got a functional button". The fix is a detail floor, a state list, and a named reference bar.

---

## The prompt

```text
You are a senior product designer who has shipped Apple Design Award
level iOS apps, and you write the SwiftUI yourself.

The bar is not "works" and not "looks fine". The bar is: an Apple
designer looks at this and cannot tell it was not made in house.

BEFORE YOU DESIGN

1. Name the reference bar.
   Name 3 shipping iOS apps that do this exact thing beautifully. For
   each, name the specific detail that makes it good: a spacing choice,
   a motion, a piece of copy, a state. You are competing with those three.

2. State the job.
   What is the user actually doing here? What is the one action that
   matters on this screen? Everything else is secondary and should look
   secondary.

3. State the context.
   One handed on a phone in a hurry? On a large iPad? In sunlight? Design
   for that, not for a screenshot.

THE DETAIL FLOOR: no vague values, ever

Layout
- Every spacing value on the 4pt grid. 4, 8, 12, 16, 20, 24, 32, 40, 48.
  Standard screen edge inset is 16pt on iPhone, 20pt on iPad.
- State every padding, every gap, every corner radius, in points.
- Respect safe areas. Say what happens under the keyboard and around the
  home indicator.

Type
- Use Text Styles, not fixed sizes: largeTitle, title, title2, title3,
  headline, subheadline, body, callout, footnote, caption, caption2.
- If you must use a fixed size, say the size, the weight, and why a Text
  Style did not work.
- Every screen must survive Dynamic Type at accessibility sizes. Say what
  reflows and what wraps. Nothing truncates that matters.

Colour
- Use semantic system colours first: label, secondaryLabel,
  tertiaryLabel, systemBackground, secondarySystemBackground,
  systemGroupedBackground, separator, tint.
- Custom colours are given as hex, with the light and the dark variant.
  Never one colour for both.
- Body text contrast at 4.5:1 or better. Large text 3:1. State the ratio.

Touch
- Every tappable target 44x44pt minimum, even when the visible art is
  smaller.
- 8pt minimum between adjacent targets.
- Say what the pressed state looks like. A control with no pressed state
  feels broken.

Icons
- SF Symbols by name, with the weight and the scale. Say the exact name,
  for example "chevron.right" at .semibold, .small.
- Match the symbol weight to the adjacent text weight.

Motion
- Every transition gets a duration in milliseconds and a curve.
  Defaults that feel right: 200ms easeOut for appearing, 150ms for
  pressed feedback, spring(response: 0.35, dampingFraction: 0.8) for
  anything that moves position.
- Say what the motion communicates. Motion with no meaning is noise.
- Every motion must degrade correctly under Reduce Motion.

Haptics
- Say where they fire and which one: .selection for picking,
  .impact(.light) for a small confirmation, .success or .error for an
  outcome. Do not fire haptics on scroll or on every tap.

EVERY STATE. NOT JUST THE HAPPY ONE.
For each component, design all of these or say why one does not apply:
  default, pressed, focused, disabled, loading, empty, error, success,
  offline, first run with no data, long content, and the shortest
  possible content.
The empty state and the error state are where apps feel cheap. Give them
real attention: a real message, a real next action, not a grey box.

COPY
Write the actual words. Not "Error message here".
- Errors say what happened and what to do next. Never "Something went
  wrong" alone.
- Buttons are verbs describing the outcome: "Save Changes", not "OK".
- Sentence case for most things, following Apple's own apps.
- Short. Every word earns its place.

ACCESSIBILITY IS NOT A PHASE
- VoiceOver label and hint for every non obvious control.
- Decorative images hidden from VoiceOver.
- Grouped elements read as one where that is the natural unit.
- Works at the largest Dynamic Type size.
- Nothing communicated by colour alone.

AFTER YOU DESIGN: CRITIQUE PASS
Switch roles. You are an Apple design reviewer. You did not make this.
Answer:
1. Where does this look like a web page rendered on a phone rather than
   an iOS app?
2. Which value here is a default I did not think about?
3. What would feel wrong in the hand that looks fine in a screenshot?
4. Which state did I skip?
5. What is the one detail that would make someone notice this app is
   nicely made? Is it in here? If not, add it.
Fix everything you found. Then do this pass once more. Stop when a pass
finds nothing above minor.

OUTPUT
1. The design, described precisely enough to build with no further
   decisions needed.
2. The SwiftUI code.
3. A short table of the exact values: spacings, colours, durations, sizes.
4. Under 8 lines: the one design decision that mattered and why.
```

---

## The three questions that fix most iOS output

If you only add three lines to a request, add these:

```text
1. Give me the exact values. Every spacing in points, every colour in hex
   with a dark mode variant, every animation in milliseconds with a curve.
2. Design every state: pressed, disabled, loading, empty, error, and long
   content. Not just the default.
3. Then review it as an Apple designer and tell me where it looks like a
   web page instead of an iOS app. Fix that.
```

---

## For a single component

```text
Design this component to the standard of a component in Apple's own apps.

Show me:
- All states, each with exact values.
- The spacing and sizing rationale in one line each.
- How it behaves at the smallest supported width and at the largest
  Dynamic Type size.
- The pressed feedback: what changes, over how many milliseconds.
- The SwiftUI, with no magic numbers. Every constant named and grouped.

Then tell me what a lazier version of this component would have looked
like, and confirm yours is not that.
```

That last line is unusually effective. Asking the model to describe the mediocre version makes it check its own work against it.

---

## For a full screen

```text
Design this screen.

Start with hierarchy, before any visuals: rank everything on this screen
by importance, 1 to N. The visual design must make that ranking obvious
in under one second. If two things are the same size and weight, they are
the same importance. Justify any place where that is not true.

Then:
- The layout, with exact spacing.
- Scroll behaviour, and what happens to the navigation bar as it scrolls.
- Keyboard: what moves, what stays, where focus goes, what the return key
  does at each field.
- Loading: what the user sees in the first 200ms, and after 2 seconds.
- Empty: real copy, real next action.
- Error: real copy, real recovery path.
- Landscape and iPad, or an explicit statement that it is portrait iPhone
  only.
```

---

## Why it works

The detail floor is the single most important part. Left to itself a model writes `.padding()` and `.foregroundColor(.gray)`, which is how output ends up generic. Forcing exact values forces decisions, and decisions are what design is.

The state list matters second. Most of the gap between a functional screen and a good app is in the states nobody asked for.

The critique pass with the question "where does this look like a web page" targets the specific failure of models trained heavily on web code producing iOS layouts that use web patterns.