Ios App

iOS App Design

Approach this as the art director and lead engineer of a studio whose apps win Apple Design Awards — the ones that feel like they belong on iOS the instant they open, yet could never be mistaken for anyone else's. You hold two loyalties at once, and the whole skill is the discipline of holding both: native (the app speaks the platform's grammar, so it's familiar in the hand) and yours (it carries an identity no competitor shares). An app that is only native is a tutorial; an app that is only distinctive fights the platform and feels wrong. Aim for native-but-yours.

Ground it in the subject

If the brief doesn't pin down what the app is, pin it yourself before designing: name the subject, its audience, and — most important — the core loop, the single interaction the user repeats every day. Check memory for the human's preferences, prior context, and anything you've built with them, and let it steer the choices. The subject's own world — its materials, rituals, vocabulary — is where a distinctive direction comes from.

The core loop is the hero. A web page's hero is a headline; an app's hero is the thing the user does for the hundredth time. Design that screen first and best — the timer they start, the card they swipe, the entry they log — and let everything else defer to it.

Design with Apple's grain — Clarity, Deference, Depth

Apple's three themes are your decision lens; reach for them by name when a choice is unclear.

• Clarity — legibility above all: Dynamic Type, honest contrast, SF Symbols at the right weight, touch targets that forgive. If a screen is hard to parse at a glance, nothing else matters.
• Deference — content leads, chrome recedes. Use system materials and translucency to let what matters sit on top; resist decorating the frame.
• Depth — layering tells the story: sheets rising, cards lifting, transitions that show where you came from. Hierarchy you can feel, not just see.

The system is your material

The iOS palette is the platform itself, and distinctiveness comes from how you push these, not from replacing them with web-style custom everything:

• San Francisco with Dynamic Type — but a bespoke display or numeral face for the hero is where personality enters.
• SF Symbols — variable weight, hierarchical rendering, built-in symbol effects (.bounce, .pulse, .variableColor). A considered symbol set reads as native and intentional at once.
• Semantic colors and system materials — they adapt to light and dark for free; layer your accent over them rather than fighting them.
• Haptics — part of the design surface, not a finishing touch.

Default-everything is the trap on one side, custom-everything is the trap on the other. Adopt the system pattern wherever users expect it (navigation, sheets, context menus, swipe actions); spend your invention where it carries the identity.

Choreography — motion and haptics together

iOS's signature feel is motion paired with a tap on the hand at the same instant. Treat them as one design material — choreography:

• Spring physics over duration curves (.bouncy, .snappy, .smooth); make animations interruptible and interactive so they track the finger.
• matchedGeometryEffect for continuity between states.
• Map haptics to moments deliberately — a soft tap on selection, a success notification on a milestone — never a buzz on everything.

Restraint still rules: gratuitous animation is the tell of AI-generated work here just as on the web. One orchestrated moment beats ten scattered effects.

Signature — and the surfaces only iOS has

Spend boldness in one place. Pick a single signature element the app is remembered by, and consider the surfaces no web app gets: the app icon, the core-loop screen, a Live Activity / Dynamic Island, a Home Screen widget, an onboarding sequence, or one choreographed haptic-and-motion moment. Make one of these unforgettable; keep everything around it quiet.

Process: brainstorm → tokens → critique → build → critique

Work in two passes, mostly in your own thinking; show the human ideas only once you're confident they'll delight.

First, brainstorm a compact token system for the app:

• Color — 4–6 named values that resolve in both light and dark, plus one accent.
• Type — a Dynamic Type scale with intentional weights, and the display treatment that carries personality.
• Motion & haptics — a few named springs, and the haptic mapped to each key moment.
• Components — which system patterns you adopt as-is, and the few you customize, and why.
• Signature — the one memorable element, named.

Then critique the token system against the default-SwiftUI cluster below before writing code. Completion criterion: every token traces to this subject, and none of them is the default an unbriefed prompt would produce — revise any that is, and say what you changed and why.

Calibration: the default-SwiftUI look to avoid

Right now AI-generated SwiftUI clusters hard around one look, and it appears regardless of subject: stock SF Pro at default weights, a single accent over systemGroupedBackground, plain List rows, rounded-rectangle cards with a soft drop .shadow, a LinearGradient from an accent to a paler tint, Capsule buttons in .bold(), and .padding() everywhere. It is competent and completely anonymous. Where the brief names a direction, follow it exactly. Where it leaves an axis free, don't spend that freedom on this cluster.

Quality floor

Build to this without announcing it: Dynamic Type scales without breaking layout, Dark Mode is real rather than an afterthought, content respects the safe areas around the Dynamic Island and home indicator, VoiceOver labels are present, Reduce Motion is honored, and every target clears 44pt. Preview in light and dark before calling a screen done.

Build

For concrete, above-default SwiftUI patterns — named spring tokens, a haptics helper, an animated number roll-up, a custom progress ring, material cards, symbol effects, and a Live Activity skeleton — read [SWIFTUI-CRAFT.md](SWIFTUI-CRAFT.md) when you start implementing. Derive every color, type, and motion decision from the token system, not from the editor's defaults.

Writing in the app

Microcopy is design material. iOS has its own writing moments: prime a permission before the system dialog (say why you need notifications, then trigger the prompt), make empty states an invitation to start the core loop, and keep notification copy specific and earned. For general UI-writing principles — active voice, naming by what the user controls, errors that direct rather than apologize — the frontend-design skill's writing guidance applies directly; reach for it rather than restating it.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: OUANZOUGUIAbdelhak
• Source: OUANZOUGUIAbdelhak/Claude-Skills
• License: MIT

Install and usage instructions live in the source repository linked above.