Claude Skills for Apple Design Work

Claude skills for Apple design work encode specific guidance from Apple's Human Interface Guidelines into reusable review instructions. Instead of describing what to check each time you review a screen, you activate a skill and Claude applies the same checklist to each review. Tools like fenbs retain the approved design rules and the lessons from real reviews between sessions, so the standard improves each time rather than starting fresh.

Apple publishes the Human Interface Guidelines↗ (opens in a new tab) (HIG) for iOS, iPadOS, macOS, watchOS and visionOS. The guidelines cover layout, navigation, controls, typography, color and platform conventions. A skill based on the HIG brings that standard into the review session without requiring the designer or reviewer to hold every rule in memory.

What to include in an Apple design review skill

A useful Apple design review skill draws from the HIG sections most relevant to the component or pattern you are reviewing. It does not attempt to cover every page of the guidelines in one instruction. Choose the checks that apply most often to the type of work you do: navigation, controls, accessibility, typography and layout cover the majority of common review issues.

Add your project-specific rules alongside the HIG checks. If your app uses a custom navigation pattern, the skill should note that. If your team has agreed on a minimum touch target size that is more conservative than Apple's default, include that. The skill becomes a combination of the published standard and the decisions your team has made on top of it.

Check Apple's own pages before including any specific rule: the HIG is updated with each platform release. See claude skills examples for patterns from other design contexts, and how to create a Claude skill for the setup steps in Claude.ai and Claude Code.

Skill: iOS or iPadOS screen review

Use this skill to review a screen design or component against iOS and iPadOS conventions. Describe the screen or share an image description after activating the skill. Include what the screen is for and where it appears in the app's navigation.

Review the iOS or iPadOS screen design I describe below against Apple Human Interface Guidelines.

Check:
1. Navigation: whether the navigation pattern matches the HIG recommendation for this type of screen (tab bar, navigation stack, modal, sheet).
2. Controls: whether interactive elements use standard iOS controls where appropriate, or clearly justify a custom approach.
3. Touch targets: whether tappable elements are large enough for comfortable use (check Apple's current HIG for the recommended minimum).
4. Typography: whether the design uses Dynamic Type or a compatible scale, and whether text is legible at the default size.
5. Accessibility: whether the screen would work without color as the only means of conveying information, and whether obvious VoiceOver labels are missing.
6. Safe areas: whether content avoids the status bar, home indicator and notch areas.

For each issue, name the element, cite the relevant HIG section if you know it, and describe what to change.

For the HIG citation in step 6, Claude will refer to the guidelines it was trained on. Check the current Apple HIG↗ (opens in a new tab) for any rule before treating it as authoritative, because the guidelines are updated regularly.

Skill: macOS interface review

Use this skill when reviewing a macOS window, dialog or menu. macOS has different conventions from iOS for navigation, density and keyboard interaction. The skill applies the platform-appropriate checks.

Review the macOS interface design I describe below against Apple Human Interface Guidelines.

Check:
1. Window structure: whether the window uses the standard toolbar, sidebar and content area layout for its type.
2. Controls: whether buttons, menus and other controls follow macOS conventions rather than iOS-style controls.
3. Keyboard access: whether all primary actions have keyboard shortcuts, and whether the interface is navigable without a mouse.
4. Density: whether the layout uses space appropriate for a desktop environment without being too sparse or too dense.
5. Menu bar integration: whether the app adds the expected menu bar items and follows the standard menu structure.

For each issue, name the element or section, describe the problem, and suggest what to change.

macOS and iOS designs share some conventions but differ significantly in interaction model and visual density. Running a separate skill for each platform avoids applying the wrong standard.

Updating skills when the HIG changes

Apple updates the Human Interface Guidelines with each major platform release, typically each fall. When a new version of the HIG is published, review your skills against the updated guidelines. Pay particular attention to sections about new system controls, display sizes for new devices, and any interaction pattern changes.

A short note about what changed -- "Updated October 2026 for HIG changes in iOS 20" -- in the skill description makes it easier to track whether you have reviewed it recently. Keep the update record in fenbs Decisions and rules so the team knows when the review was done and by whom.

How to do this with fenbs

1. Create a free account and add a project for your Apple platform app.
2. Add the platform targets as tasks or project context: which platforms, which OS versions, which device sizes you are designing for.
3. Save the iOS and macOS review skills in fenbs Skills and prompts with names that make the platform clear.
4. Record the team's agreed deviations from the HIG in Decisions and rules: why you use a custom navigation pattern, which accessibility target you have committed to, any HIG section where you chose a different approach.
5. After each review, add a lesson if a real user-facing problem was caught or missed. Update the relevant skill to include any new check that would have caught it.

When these skills are not the right fit

These skills work best for teams building native Apple platform apps with a meaningful volume of design review work. A single developer building a hobby app may not need a formal review skill. A team shipping to the App Store on a regular cadence, where HIG compliance affects review outcomes, benefits from having consistent review language. See claude design for broader design use cases beyond platform-specific review.

Also consider the scope of each review. These skills cover the most common HIG checks for layout, controls, accessibility and navigation. They do not cover every guideline section: App Store review requirements, specific widget or extension guidelines, or platform-specific details for watchOS and visionOS each need their own focused skill. Treat these templates as a starting point and expand them as your review practice develops and as new platform guidance is published.