Use when making design decisions, reviewing UI for HIG compliance, choosing colors/backgrounds/typography, or defending design choices - quick decision frameworks and checklists for Apple Human Interface Guidelines
/plugin marketplace add CharlesWiltgen/Axiom/plugin install axiom@axiom-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Use when:
axiom-hig-ref for comprehensive details and code examplesaxiom-liquid-glass for iOS 26 material design implementationaxiom-liquid-glass-ref for iOS 26 app-wide adoption guideaxiom-accessibility-diag for accessibility troubleshootingIs your app media-focused (photos, videos, music)?
├─ Yes → Consider permanent dark appearance
│ WHY: "Lets UI recede, helps people focus on media" (Apple HIG)
│ EXAMPLES: Apple Music, Photos, Clock apps use dark
│ CODE: .preferredColorScheme(.dark) on root view
│
└─ No → Use system backgrounds (respect user preference)
CODE: systemBackground (adapts to light/dark automatically)
GROUPED: systemGroupedBackground for iOS Settings-style lists
Apple's guidance: "In rare cases, consider using only a dark appearance in the interface. For example, it can make sense for an app that enables immersive media viewing to use a permanently dark appearance."
Do you need a specific color value?
├─ No → Use semantic colors
│ label, secondaryLabel, tertiaryLabel, quaternaryLabel
│ systemBackground, secondarySystemBackground, tertiarySystemBackground
│ WHY: Automatically adapts to light/dark/high contrast
│
└─ Yes → Create Color Set in asset catalog
1. Open Assets.xcassets
2. Add Color Set
3. Configure variants:
├─ Light mode color
├─ Dark mode color
└─ High contrast (optional but recommended)
Key principle: "Use semantic color names like labelColor that automatically adjust to the current interface style."
Which font weight should I use?
├─ ❌ AVOID: Ultralight, Thin, Light
│ WHY: Legibility issues, especially at small sizes
│
├─ ✅ PREFER: Regular, Medium, Semibold, Bold
│ WHY: Maintains legibility across sizes and conditions
│
└─ Headers: Semibold or Bold for hierarchy
Body: Regular or Medium
Apple's guidance: "Avoid light font weights. Prefer Regular, Medium, Semibold, or Bold weights instead of Ultralight, Thin, or Light."
Verify every screen passes these checks:
A: Only for media-focused apps (photos, videos, music) where content should be the hero. Use system backgrounds for everything else.
Apple's own apps:
| App | Background | Reason |
|---|---|---|
| Music | Dark | Album art is focus |
| Photos | Dark | Images are hero |
| Clock | Dark | Nighttime use |
| Notes | System | Document editing |
| Settings | System | Utilitarian |
Code:
// ❌ WRONG - Don't override unless media-focused
.background(Color.black)
// ✅ CORRECT - Let system decide
.background(Color(.systemBackground))
A: Use systemBackground which adapts to light/dark automatically. For grouped content (like iOS Settings), use systemGroupedBackground.
Color hierarchy:
systemBackground - Main backgroundsecondarySystemBackground - Grouping elementstertiarySystemBackground - Grouping within secondary// ✅ Standard list
List { }
.background(Color(.systemBackground))
// ✅ Grouped list (Settings style)
List { }
.listStyle(.grouped)
.background(Color(.systemGroupedBackground))
A: Use semantic label colors, maintain 4.5:1 contrast, avoid light font weights.
Label hierarchy:
// Most prominent
Text("Title").foregroundStyle(.primary)
// Subtitles
Text("Subtitle").foregroundStyle(.secondary)
// Tertiary information
Text("Detail").foregroundStyle(.tertiary)
// Disabled text
Text("Disabled").foregroundStyle(.quaternary)
A: SF Symbols unless you need brand-specific imagery. They scale with Dynamic Type and adapt to appearance automatically.
Benefits of SF Symbols:
When to use custom:
A: Always support both. Never create app-specific appearance settings.
Apple's guidance: "Avoid creating app-specific appearance settings. Users expect apps to honor their systemwide Dark Mode choice. An app-specific appearance mode option creates more work for people because they have to adjust more than one setting to get the appearance they want."
A: 4.5:1 minimum for normal text, 7:1 recommended for small text.
WCAG Contrast Standards:
Testing: Use online contrast calculators or Xcode's Accessibility Inspector.
A: 44x44 points on iOS/iPadOS, with spacing between targets.
Platform-specific:
Use this checklist for design reviews, App Store submissions, or stakeholder presentations:
In design reviews, you'll hear:
These violate HIG. Here's how to push back professionally.
If you hear ANY of these, reference this skill:
"I want to make this change, but let me show you Apple's guidance:
[Show the relevant HIG section from this skill or hig-ref]
Apple explicitly recommends against this because..."
For contrast issues:
For appearance toggles:
"I understand the brand concern. Here are HIG-compliant alternatives:
1. Use your brand color as the app's tint color
2. Feature branding in onboarding (not launch screen)
3. Use your accent color for primary actions
4. Include subtle branding in content, not chrome"
If overruled:
Slack message to PM + designer:
"Design review decided to [violate HIG guidance].
Important risks to monitor:
- App Store rejection (HIG violations)
- Accessibility issues (users with visual impairments)
- User complaints (departure from platform norms)
I'm flagging this proactively. If we see issues after launch,
we'll need an expedited follow-up."
Sometimes designers have valid reasons to override HIG. Accept if:
Every design decision should support these principles:
Definition: Content should be paramount, interface elements should defer to content.
In practice:
Definition: Use standard UI elements and familiar patterns.
In practice:
Definition: UI shouldn't compete with content for attention.
In practice:
From HIG: "Deference makes an app beautiful by ensuring the content stands out while the surrounding visual elements do not compete with it."
WWDC: 356, 2019-808
Docs: /design/human-interface-guidelines, /design/human-interface-guidelines/color, /design/human-interface-guidelines/dark-mode, /design/human-interface-guidelines/typography
Skills: axiom-hig-ref, axiom-liquid-glass, axiom-liquid-glass-ref, axiom-accessibility-diag
Last Updated: Based on Apple HIG (2024-2025), WWDC25-356, WWDC19-808 Skill Type: Discipline (Quick decisions, checklists, pressure scenarios)
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.