Plan and de-risk native iOS app work with stronger design direction. Use when Codex needs to choose Swift as the default language for a new iOS app, decide between SwiftUI and UIKit, shape a distinctive UI art direction, choose system components or focused UI helpers, define theme colors and typography, or pick animation approaches like native SwiftUI motion, Lottie, Rive, or Hero. Trigger on requests about iOS app planning, 语言选择, 组件库, UI风格, 主题配色, 动画库, 视觉方案, 设计方向, 界面美化, or app 启动方案.
Use this skill before implementation when an iOS app idea is still vague or when UI direction stalls. Ask a short discovery set, default to the native Apple stack, and return a concrete build brief with stack, art direction, typography, layout language, color tokens, motion choice, and next steps.
Workflow
Ask up to five short questions that will change the technical decision.
Commit to a clear visual point of view before naming libraries.
Decide the stack with a bias toward Swift + SwiftUI.
Choose UI building blocks instead of chasing a generic "pretty component library".
Define typography, layout rhythm, surface treatment, and a semantic color system.
Choose motion tooling only if native animation is not enough.
Return a compact build brief with explicit assumptions and one memorable signature idea.
Discovery Questions
Ask only what will materially change the plan:
What does the app do, and who is the primary user?
Verwandte Skills
Is this native iOS only, or is there real cross-platform pressure?
Is this a greenfield app or an existing UIKit / Objective-C codebase?
What are the main constraints: minimum iOS version, deadline, team experience, accessibility, design assets?
What tone should the app feel like: trustworthy, calm, energetic, premium, playful, or minimal?
What visual direction should the interface lean toward: editorial, glassy, tactile, clinical, sporty, luxurious, toy-like, or quiet utility?
What should make the UI memorable after ten seconds of use: typography, cards, imagery, icon motion, depth, or a specific hero interaction?
What motion is actually needed: none, subtle feedback, onboarding loops, interactive state machines, or shared-element transitions?
If the user omits an answer, make a reasonable assumption and label it explicitly.
Stack Decision
Default a new native iOS app to Swift + SwiftUI.
Use UIKit when working inside an existing UIKit codebase, when heavy view-controller coordination is already present, or when UIKit-only transitions and imperative control are the main constraint.
Use a hybrid approach when most screens can be SwiftUI but one or two features need UIKit escape hatches.
Avoid Objective-C for new work unless the repository already depends on it.
If the user explicitly needs one codebase for both iOS and Android, state that this becomes a product-stack decision outside the default native path; do not derail a native iOS brief unless the user asks.
Do not settle for "clean modern app" as a design direction. Name a stronger concept and execute it consistently.
Pick one memorable signature element such as editorial type contrast, liquid-glass depth, oversized cards, diagram-like iconography, or a dramatic hero transition.
Keep the interface native in interaction even when the visual language is bold.
Use contrast intentionally: refined minimalism, athletic energy, calm clinical clarity, playful tactility, or premium instrument-panel precision can all work if the direction is coherent.
Prefer Apple system components, SF Symbols, system materials, and custom design tokens over a heavy third-party UI kit.
Treat "更漂亮" as a design-system problem: hierarchy, spacing, type scale, iconography, surfaces, and motion.
Use focused libraries only to fill a specific gap. Do not add a dependency only because the UI feels plain.
Preserve Apple ergonomics and accessibility while pushing the visual direction through composition and styling.
Typography And Layout
Use SF Pro as the default body typeface for product UI because it is the system font and designed for legibility on Apple platforms.
Consider New York for reading-heavy, editorial, or premium display moments.
Add a custom font only when it reinforces the concept and does not damage readability, localization, or Dynamic Type support.
Define a visible type hierarchy, spacing rhythm, corner-radius family, and density model before polishing individual screens.
Use asymmetry, overlap, section contrast, or spacious negative space when the concept calls for it, but keep navigation and touch targets predictable.
Theme
Pick one accent family, one neutral family, and explicit semantic colors.
Always consider light mode, dark mode, contrast, and accessibility before locking the palette.
Prefer system-defined or asset-catalog-driven colors that can adapt with the environment.
Use backgrounds, materials, gradients, imagery, or texture only when they reinforce the concept; avoid flat default screens unless minimalism is the actual direction.
Use python3 scripts/generate_theme_tokens.py --mood trust to get a starting palette, or pass --accent HEX after the brand direction is clear.