Audits and designs iOS/macOS/watchOS/visionOS interfaces against the Apple Human Interface Guidelines, including the Liquid Glass design language (announced WWDC25, shipped with iOS 26/macOS Tahoe, Sept 2025). Use when reviewing an Apple-platform mockup or app for HIG compliance, checking contrast or tap-target sizes, or designing native-feeling Apple UI (e.g., 'audit my iOS app against the HIG',
cd ~/.claude/skills
git clone https://github.com/alirezarezvani/claude-skills.git claude-skills mkdir -p ~/.claude/skills/apple-hig-expert
curl -fsSL https://raw.githubusercontent.com/alirezarezvani/claude-skills/HEAD/.gemini/skills/apple-hig-expert/SKILL.md \
-o ~/.claude/skills/apple-hig-expert/SKILL.md Design and audit apps against the Apple Human Interface Guidelines (HIG, developer.apple.com/design/human-interface-guidelines), including the Liquid Glass design language. HIG content evolves with each OS release — when a claim matters, verify against the live HIG pages cited in references/.
If product-context.md or ios-design-context.md exists, read it before asking questions. Then gather:
references/platform-specifics.md), then apply typography and semantic color (references/visual-design.md).templates/hig-audit-template.md, run scripts/hig_checker.py on every measurable element, and deliver a scored report (see Worked example below).scripts/hig_checker.py (stdlib-only) has three subcommands:
# 1. Contrast ratio (WCAG formula; pass >= 4.5:1 for normal text)
python3 scripts/hig_checker.py contrast "#8E8E93" "#FFFFFF"
# -> Contrast Ratio: 3.26 [FAILED]
# 2. Tap-target size (pass >= 44x44 pt per HIG)
python3 scripts/hig_checker.py target 32 32
# -> Tap Target: 32x32 [FAILED]
# 3. Batch audit from JSON -> scorecard (starts at 100, -10 per violation)
python3 scripts/hig_checker.py batch audit.json
Batch input shape:
{
"checks": [
{"type": "contrast", "name": "caption-on-card", "fg": "#8E8E93", "bg": "#FFFFFF"},
{"type": "target", "name": "close-button", "w": 32, "h": 32}
]
}
Scorecard rubric: the batch score starts at 100 and subtracts 10 per failed check; violations are listed by element name. 90-100 = ship, 70-80 = fix before release, below 70 = systematic rework. Checks the tool cannot measure (VoiceOver labels, Dynamic Type behavior, Reduce Transparency) are assessed manually via the audit template and tagged with confidence.
Input: mockup with body text #1C1C1E and captions #8E8E93 on white cards, a 32x32 pt close button, and a 343x50 pt primary CTA.
Run:
python3 scripts/hig_checker.py batch audit.json
Output (real):
{
"score": 80,
"violations": [
"Contrast 3.26 fails for caption-on-card",
"Target 32x32 small for close-button"
]
}
Findings → fixes (bottom line first):
HIG score 80/100 — two fixes before release.
- Captions fail contrast (3.26 < 4.5). Use
.secondaryLabel(semantic color) instead of hardcoded#8E8E93, or darken to ≥#6E6E73on white. 🟢 verified by tool.- Close button is 32x32 pt (< 44x44 minimum). Keep the glyph small but expand the hit region to 44x44 with padding/
contentShape. 🟢 verified by tool.- Manual check: the card uses an ultra-thin material over a photo background — re-test caption contrast against the busiest underlying region and with Reduce Transparency on. 🟡 needs device test.
glassEffect view modifier; keep hierarchy between content and controls. See references/visual-design.md.references/accessibility.md.references/platform-specifics.md.Surface these WITHOUT being asked: low contrast over translucent layers; interactive elements under 44 pt; icon buttons with no accessibility label; density overload (no breathing room between glass layers).
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions