home / skills / rshankras / claude-code-apple-skills / ui-review

ui-review skill

/skills/ios/ui-review

This skill reviews SwiftUI code for HIG compliance, dynamic type, fonts, and accessibility to ensure Apple-standard interfaces.

This is most likely a fork of the ios skill from rshankras
npx playbooks add skill rshankras/claude-code-apple-skills --skill ui-review

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
5.7 KB
---
name: ui-review
description: Review SwiftUI code for iOS/watchOS Human Interface Guidelines compliance, font usage, Dynamic Type support, and accessibility. Use when user mentions UI review, HIG, accessibility audit, font checks, or wants to verify interface design against Apple standards.
allowed-tools: [Read, Glob, Grep, WebFetch]
---

# UI Review Skill

Performs comprehensive UI/UX review of SwiftUI code against Apple's Human Interface Guidelines, font best practices, and accessibility standards for iOS and watchOS.

## When This Skill Activates

Use this skill when the user:
- Asks to review UI/UX code
- Mentions HIG compliance or Apple guidelines
- Requests accessibility audit
- Wants font usage checked
- Asks about Dynamic Type support
- Requests design review against Apple standards

## Review Process

### 1. Identify Files to Review

- If user specifies files/views, review those
- Otherwise, ask which views to review or scan recent SwiftUI files
- Prioritize user-facing views over components

### 2. Load Reference Materials

Before starting the review, familiarize yourself with the reference materials by reading the following files in `.claude/skills/ui-review/`:

- **hig-checklist.md** - Comprehensive HIG compliance checklist for iOS and watchOS
- **font-guidelines.md** - Font usage, Dynamic Type, and typography best practices
- **accessibility-quick-ref.md** - Quick reference for accessibility implementation

You may also reference the official Apple guidelines using WebFetch when needed:
- **iOS HIG**: https://developer.apple.com/design/human-interface-guidelines/designing-for-ios
- **watchOS HIG**: https://developer.apple.com/design/human-interface-guidelines/designing-for-watchos

### 3. Review Categories

Apply these review categories based on the code type:

**HIG Compliance:**
- Layout & spacing (tap targets, safe areas, padding)
- Navigation patterns (NavigationStack, sheets, alerts)
- Colors & visuals (semantic colors, dark mode, contrast)
- Platform-specific requirements (iOS vs watchOS)
- Loading/empty/error states

**Font Usage:**
- Dynamic Type support
- System text styles vs fixed sizes
- Font hierarchy and semantic usage
- Custom fonts scaling properly
- Text formatting and truncation

**Accessibility:**
- Labels and hints for interactive elements
- Traits and roles
- VoiceOver navigation order
- Custom actions
- Dynamic content announcements
- Testing with assistive technologies

### 4. Common Issues to Flag

**Anti-patterns:**
- Hardcoded colors (`.foregroundColor(.black)`)
- Fixed font sizes (`.font(.system(size: 14))`)
- Missing accessibility labels on icon-only buttons
- Tap targets smaller than 44pt (iOS) or 40pt (watchOS)
- Important info conveyed by color only
- Missing loading/error states
- Direct UIColor usage (use `Color(.systemBackground)`)
- `.frame()` without considering Dynamic Type expansion
- Missing keyboard shortcuts (iPad/Mac)

**Good Patterns:**
- Semantic color usage
- System font styles with Dynamic Type
- Comprehensive accessibility labels
- Clear visual hierarchy
- Consistent spacing
- Proper error handling
- Responsive layouts

## Output Format

Provide review in this structure:

### ✅ HIG Compliance
- List items that comply well
- Highlight good practices

### ⚠️ HIG Issues Found
- Specific line references: `filename.swift:lineNumber`
- Description of issue
- Suggested fix with code example

### ✅ Font Usage
- Proper Dynamic Type usage
- Good font hierarchy

### ⚠️ Font Issues Found
- Hardcoded sizes or missing Dynamic Type support
- Suggested fixes

### ✅ Accessibility
- Well-implemented accessibility features
- Good label/hint usage

### ⚠️ Accessibility Issues Found
- Missing labels or hints
- Incorrect traits
- Navigation problems
- Suggested fixes with code examples

### 📋 Testing Recommendations
- Specific tests to run (VoiceOver, Dynamic Type, Dark Mode)
- Accessibility Inspector checks
- Device/simulator testing suggestions

## Example Review Output

```
Reviewing: AddOrUpdateExpenseView.swift

✅ HIG Compliance
- Good use of semantic colors throughout
- Proper NavigationStack implementation
- Safe area handling is correct

⚠️ HIG Issues Found
1. AddOrUpdateExpenseView.swift:145 - Delete button tap target may be small
   Suggested fix: Ensure .frame(minWidth: 44, minHeight: 44)

2. AddOrUpdateExpenseView.swift:203 - Hardcoded color
   Current: .foregroundColor(.red)
   Suggested: .foregroundColor(Color(.systemRed))

✅ Font Usage
- Excellent use of .headline for section headers
- Proper .body for content text

⚠️ Font Issues Found
1. AddOrUpdateExpenseView.swift:178 - Hardcoded font size
   Current: .font(.system(size: 14))
   Suggested: .font(.subheadline)

✅ Accessibility
- Good labels on most form fields
- Proper form structure

⚠️ Accessibility Issues Found
1. AddOrUpdateExpenseView.swift:92 - Icon button missing label
   Current: Button { } label: { Image(systemName: "calendar") }
   Suggested: Add .accessibilityLabel("Select date")

📋 Testing Recommendations
1. Test with VoiceOver enabled
2. Test at largest Dynamic Type size (Accessibility → Display)
3. Verify in Dark Mode
4. Use Accessibility Inspector to check contrast ratios
```

## References

Always reference these when in doubt:
- [iOS HIG](https://developer.apple.com/design/human-interface-guidelines/designing-for-ios)
- [watchOS HIG](https://developer.apple.com/design/human-interface-guidelines/designing-for-watchos)
- [SF Symbols](https://developer.apple.com/sf-symbols/)
- [Accessibility on Apple platforms](https://developer.apple.com/accessibility/)

## Notes

- Be constructive and specific
- Provide code examples for fixes
- Reference exact line numbers
- Prioritize user-impacting issues
- Consider context (some exceptions are valid)

Overview

This skill reviews SwiftUI code against Apple Human Interface Guidelines for iOS and watchOS, focusing on HIG compliance, font usage, Dynamic Type support, and accessibility. It provides actionable findings with file:line references, suggested fixes, and code examples. Use it to catch platform-specific anti-patterns and to improve usability, accessibility, and visual consistency.

How this skill works

I inspect specified SwiftUI view files (or prompt you to pick views) and run a checklist covering layout, navigation, color semantics, font strategy, and accessibility hooks. Reviews highlight good patterns, list concrete issues with exact file:line locations, and include suggested fixes and small code snippets to correct problems. I also recommend targeted tests (VoiceOver, Dynamic Type, Dark Mode) and platform-specific checks for iOS vs watchOS.

When to use it

  • When you ask for a UI review, HIG compliance check, or Apple guidelines audit
  • When you want an accessibility audit or VoiceOver readiness check
  • When verifying Dynamic Type and font scaling across views
  • When checking color semantics, dark mode, and contrast
  • When reviewing tap targets, navigation, and platform-specific patterns

Best practices

  • Prefer semantic Color and system font styles (.headline, .body) to support Dark Mode and Dynamic Type
  • Avoid fixed .font(size:) and hardcoded colors; use system styles and Color(.systemBackground) where appropriate
  • Ensure tap targets meet minimum sizes (44pt iOS, 40pt watchOS) and use accessible labels for icon-only controls
  • Structure views for VoiceOver order, provide accessibilityLabel/hint, and expose custom actions where needed
  • Handle loading, empty, and error states explicitly and test across different content sizes

Example use cases

  • Audit a new settings screen for HIG compliance and accessibility before shipping
  • Scan an app update to ensure custom fonts scale correctly with Dynamic Type
  • Verify that icon-only toolbar buttons include accessibility labels
  • Check watchOS complication-like views for tap target and contrast compliance
  • Validate dark mode and semantic color usage across the main app views

FAQ

What files should I provide for review?

Provide the SwiftUI view files you want reviewed; if unsure, include top-level user-facing views and any custom components used by them.

Do you fix code or just report issues?

I provide precise findings and suggested code snippets for fixes. You can request patched examples and I can produce updated snippets for specific files and lines.