mobile-ios-design

Overview of mobile-ios-design skill

What the mobile-ios-design skill does

The mobile-ios-design skill helps an agent produce iOS-native interface guidance and SwiftUI-oriented UI patterns instead of generic mobile design advice. It is built around Apple Human Interface Guidelines principles and practical SwiftUI examples for layout, navigation, components, accessibility, Dynamic Type, and adaptive behavior across iPhone and iPad.

Who should use mobile-ios-design

This skill is a strong fit for:

• UI designers translating product flows into iOS-native screens
• SwiftUI developers who want structure, patterns, and platform-consistent decisions
• Product teams reviewing whether a design feels like iOS rather than cross-platform UI
• Agents asked to propose screens, navigation, or component choices for Apple platforms

If you need Android parity, a design system audit, or pixel-perfect Figma output, this skill is narrower than that. Its value is platform fit.

The real job-to-be-done

Most users do not need a lecture on Apple guidelines. They need help turning a rough feature idea like “build settings, detail, and list screens for an iPhone app” into choices that match iOS expectations: NavigationStack, TabView, sheets, list styles, spacing, safe areas, typography, SF Symbols, and adaptive layouts.

Why this skill is better than a generic prompt

A generic prompt may suggest broadly “clean mobile UI.” The mobile-ios-design skill gives the agent a stronger default frame:

• HIG principles: clarity, deference, depth
• iOS-specific navigation patterns
• SwiftUI layout examples
• common component patterns already expressed in code
• attention to Dynamic Type, Dark Mode, and accessibility

That makes it more useful when you want implementable output, not just visual direction.

What matters before you install

The skill is reference-driven. The most useful assets are:

• SKILL.md
• references/hig-patterns.md
• references/ios-navigation.md
• references/swiftui-components.md

There are no helper scripts or automation layers here, so adoption is easy, but output quality depends heavily on how specific your request is.

How to Use mobile-ios-design skill

Install context for mobile-ios-design

Install the skill into your agent environment with:

npx skills add https://github.com/wshobson/agents --skill mobile-ios-design

Because the upstream skill does not include automation scripts, mobile-ios-design install is mostly about making the references available so the agent can ground its design decisions in the provided examples.

Read these files first

For fastest understanding, read in this order:

1. SKILL.md
2. references/hig-patterns.md
3. references/ios-navigation.md
4. references/swiftui-components.md

This reading path matters because the skill starts with principles, then moves into app structure, then concrete SwiftUI building blocks.

What input the skill needs to work well

The mobile-ios-design usage quality depends on whether you provide:

• app type or feature area
• target platform: iPhone only, iPad, or both
• screen list or user flow
• navigation model
• content density and hierarchy
• accessibility needs
• whether you want design guidance, SwiftUI code, or both

Weak input:

• “Design an iOS app screen”

Strong input:

• “Design a SwiftUI iPhone app flow for a personal finance app with a dashboard, transaction list, transaction detail, and settings. Use NavigationStack, native list patterns, support Dynamic Type, and suggest SF Symbols.”

The second prompt gives the skill enough structure to choose appropriate patterns.

Turn a rough goal into a complete prompt

A good mobile-ios-design guide prompt usually includes four layers:

1. Product goal
   “Create an iOS reading app for saving and organizing articles.”

2. Screen scope
   “Need Home, Saved, Article Detail, Search, and Settings.”

3. Platform constraints
   “SwiftUI, iPhone first, iPad adaptive layout later, iOS 16+.”

4. Output format
   “Recommend navigation, component choices, spacing rules, and starter SwiftUI view structure.”

Example:

Use the mobile-ios-design skill to propose an iOS-native SwiftUI architecture for a habit tracker. Include tab structure, list and detail screens, modal usage, spacing guidance, accessibility considerations, and starter component patterns for iPhone and iPad.

Best workflow for mobile-ios-design usage

A practical workflow is:

1. Ask for screen architecture and navigation first.
2. Ask for per-screen component recommendations second.
3. Ask for SwiftUI skeletons third.
4. Refine for accessibility, Dynamic Type, and iPad adaptation after that.

This sequence works better than asking for everything at once because navigation and information hierarchy drive most downstream UI decisions.

How to ask for navigation correctly

The skill has clear value when the problem involves native iOS navigation choices. Be explicit about whether you need:

• hierarchical drill-down with NavigationStack
• top-level sections with TabView
• transient tasks with sheets
• deep linking or programmatic navigation

If you omit this, the agent may choose a valid but less suitable pattern. The references include concrete NavigationStack examples, so requests tied to modern iOS navigation tend to produce stronger output.

How to use mobile-ios-design for UI Design reviews

The mobile-ios-design for UI Design use case is not only greenfield design. It is also useful for reviews such as:

• “Does this screen violate iOS expectations?”
• “Should this action be a sheet, push, or full-screen flow?”
• “Is this layout too dense for Dynamic Type?”
• “Which list style fits this information?”

That makes the skill useful for critique and refactoring, not just first drafts.

What the skill is strongest at

This skill is strongest when you ask for:

• native layout and spacing decisions
• SwiftUI component selection
• list, form, card, and collection patterns
• iOS navigation structure
• adaptive behavior across size classes
• accessibility-aware interface choices

It is less differentiated for branding, custom visual language, or motion-heavy concept design.

What to expect from the references

The references are practical and code-oriented:

• references/hig-patterns.md covers spacing, safe areas, and adaptive layout patterns
• references/ios-navigation.md covers NavigationStack and related flows
• references/swiftui-components.md covers common building blocks like lists and search

That means the skill is especially useful if you want recommendations that can quickly become SwiftUI implementation.

Common prompt patterns that work well

Good prompt types include:

• “Recommend the right iOS navigation pattern for this feature”
• “Convert this web-style settings screen into an iOS-native SwiftUI design”
• “Design a form flow that handles validation, keyboard, and safe-area behavior”
• “Refactor this feature to better support Dynamic Type and Dark Mode”
• “Generate starter SwiftUI screen structures using native components”

Misfit cases to avoid

Do not choose mobile-ios-design skill if your main need is:

• Android Material guidance
• cross-platform design tokens
• Figma plugin automation
• advanced animation choreography
• backend or app architecture unrelated to UI

In those cases, an ordinary prompt or another skill may be a better fit.

mobile-ios-design skill FAQ

Is mobile-ios-design beginner friendly

Yes, if you already know basic iOS or SwiftUI terms. The examples are concrete enough to guide beginners, but the skill assumes you understand concepts like lists, navigation, sheets, and size classes.

Does mobile-ios-design require SwiftUI

No, but it is clearly optimized for SwiftUI. The examples and patterns lean heavily on SwiftUI components and layout. If your app is UIKit-first, the design guidance still helps, but implementation examples will need translation.

Is this skill useful without writing code

Yes. You can use mobile-ios-design to decide screen structure, navigation, and component choices before implementation. It is still valuable for product and design discussions because it frames decisions in iOS-native terms.

How is this different from asking ChatGPT for iOS UI ideas

The difference is grounding. The mobile-ios-design guide has a built-in reference set covering HIG principles, navigation patterns, and SwiftUI components. That usually leads to more platform-consistent answers and fewer generic “mobile app” suggestions.

When should I not use mobile-ios-design

Skip it when the main deliverable is:

• a branded visual exploration
• a non-Apple platform design
• code outside UI concerns
• design-system governance across many platforms

This skill is intentionally focused on native Apple interface patterns.

Can mobile-ios-design help with accessibility

Yes. It explicitly aligns well with accessibility-related asks such as Dynamic Type, legibility, Dark Mode support, and touch-friendly UI decisions. You still need to ask for these constraints directly to make them first-class in the output.

Does the skill cover iPad layouts too

Yes, at a pattern level. The source mentions adaptive layouts and size-class-aware behavior. If iPad matters, state that early so the agent does not overfit to compact iPhone layouts.

How to Improve mobile-ios-design skill

Give the skill concrete product context

The fastest way to improve mobile-ios-design usage is to stop asking for “an iOS screen” and instead provide:

• user type
• main task
• key content on screen
• primary and secondary actions
• navigation entry and exit points

This lets the skill choose the right native pattern instead of inventing one from weak context.

Ask for decisions, not just mockups

Better outputs come from prompts like:

• “Choose between TabView and sidebar-plus-detail”
• “Decide whether this edit flow should be a sheet or pushed screen”
• “Recommend list style and row density for frequent scanning”

These force the agent to use the skill's references instead of producing shallow visual description.

Include platform and OS constraints

If you want strong mobile-ios-design install value after adoption, specify technical boundaries:

• iOS 16+ or earlier
• iPhone only or universal
• portrait only or adaptive
• SwiftUI only or mixed stack

Without this, the output may stay too general to implement cleanly.

Provide content examples

Real labels improve UI quality. Compare:

Weak:

• “Design a profile screen”

Better:

• “Design a profile screen with avatar, display name, email, notification preferences, subscription state, and sign-out action”

The second prompt helps the skill determine grouping, list sections, hierarchy, and navigation affordances.

Request output in staged layers

A strong iteration pattern is:

1. information architecture
2. navigation model
3. per-screen layout
4. component selection
5. SwiftUI starter code
6. accessibility pass

This avoids getting a polished-looking answer built on weak structural choices.

Watch for common failure modes

The main failure modes with mobile-ios-design are:

• prompts too vague to select native patterns
• over-requesting branding when the skill is platform-pattern focused
• forgetting iPad or accessibility requirements
• asking for visual novelty that conflicts with HIG consistency

When results feel generic, the problem is often missing product constraints, not the skill itself.

Improve outputs with direct reference cues

You can get sharper answers by naming the area you want the agent to lean on:

• “Use the navigation patterns from references/ios-navigation.md”
• “Ground spacing and safe-area choices in references/hig-patterns.md”
• “Use list and search ideas from references/swiftui-components.md”

This is especially helpful when you want code-adjacent recommendations rather than high-level UX commentary.

Iterate after the first draft

After the first output, ask targeted follow-ups such as:

• “Make this screen work better for Dynamic Type”
• “Adapt this layout for iPad regular width”
• “Reduce visual density while keeping all actions”
• “Replace custom controls with more native SwiftUI components”

These follow-ups are where the mobile-ios-design skill often becomes more valuable than a one-shot prompt.

Use it to refactor non-native designs

One high-value pattern is to bring an existing design and ask:

• what feels un-iOS
• which controls should become native components
• how navigation should change
• where spacing, hierarchy, or safe-area handling breaks platform expectations

That is often a better use of the skill than asking for a blank-page concept.

Know the ceiling of the skill

mobile-ios-design improves decision quality most when the task is “make this feel like iOS.” It is not a replacement for full product design research, usability testing, or Apple documentation review for edge cases. Treat it as a focused accelerator for native UI structure and SwiftUI-friendly design choices.