Reviews Swift/iOS code for adherence to modern Swift idioms, Apple platform best practices, architecture patterns, and code quality standards. Use when user mentions best practices, code review, clean code, refactoring, or wants to improve code quality.
npx skills add https://github.com/rshankras/claude-code-apple-skills --skill coding-best-practices
Reviews Swift/iOS code for adherence to modern Swift idioms, Apple platform best practices, architecture patterns, and code quality standards.
Use this skill when the user:
Before starting the review, familiarize yourself with the reference patterns by reading the following files in .claude/skills/coding-best-practices/:
Apply these review categories based on the code type:
For All Code:
For SwiftUI Code:
@State, @Observable + @Bindable; legacy @StateObject / @ObservedObject pre-iOS 17)For ViewModels:
For Core Data Code:
Provide review in this structure:
For each issue, use this format:
Category: [Category Name]
[Priority]: [File.swift:line] - [Issue description]
// Current:
[problematic code]
// Suggested:
[improved code]
// Reason: [explanation]
Priority Levels:
Overall: X/10
List 3-5 easy fixes that provide immediate value
Use this comprehensive checklist during review:
The default APIs to expect in a healthy SwiftUI codebase. During review, flag code still on the legacy column — each line is: reach for this / when. Version floors in parentheses; anything unmarked is broadly available.
Structure & navigation
NavigationStack / NavigationSplitView — NavigationView is deprecated; value-based links + navigationDestination (iOS 16+)State & data flow
@Observable over ObservableObject — per-property invalidation means fewer re-renders, no @Published (iOS 17+)@State lazily initializes @Observable classes (behavior backported to iOS 17) — delete double-initialization workarounds and "cheap placeholder default" hacks@Previewable inside #Preview — use @State directly in a preview without a wrapper view (Xcode 16+)Presentation & input
presentationDetents for resizable sheets — half-height/custom stops instead of full-screen covers (iOS 16+)alert(_:item:) / confirmationDialog(_:item:) — prefer over isPresented + a side-car state variable; the item carries the context (WWDC26)searchable with scopes, tokens, and suggestions + searchFocused for programmatic search-field focus — structured search over hand-rolled filter bars@FocusState + defaultFocus + focused(_:equals:) for focus management; onKeyPress for hardware-keyboard handling.smooth / .snappy / .bouncy — sensible spring defaults before hand-tuning stiffness/damping (iOS 17+)Scrolling
.scrollTargetBehavior(.paging) / .viewAligned, scrollPosition, onScrollGeometryChange / onScrollVisibilityChange — paging, position control, and scroll-driven effects without GeometryReader + preference-key plumbing (iOS 17+)Content & media
ShareLink + Transferable — system share sheet from a declarative type conformance (iOS 16+)PhotosPicker — out-of-process photo selection, no permission prompt (iOS 16+)AsyncImage participates in HTTP caching by default (WWDC26); set asyncImageURLSession for custom cache/auth policiesLists & collections
reorderable() on ForEach and swipeActions outside List — drag-reorder and swipe in lazy stacks/grids too (WWDC26)Layout, effects & design
visualEffect over GeometryReader for visual-only geometry (scroll parallax, proximity scaling) — reads geometry without changing layout (iOS 17+)glassEffect() + ToolbarSpacer + bottom-aligned search for the system design language (iOS 26+) — route deep Liquid Glass work to design/liquid-glass@ContentBuilder as the ViewBuilder evolution — one builder for content usable across views, widgets, and app intents (WWDC26)Reviewing: ExpenseViewModel.swift
✅ Strengths Found
- Excellent use of @Published properties
- Clean separation between public and private methods
- Good error handling with custom error types
- Proper use of guard statements for early returns
⚠️ Issues Found
**Category: Optionals Handling**
**High Priority: ExpenseViewModel.swift:45** - Force unwrapping
// Current:
let payer = expense.payer!
// Suggested:
guard let payer = expense.payer else {
print("Expense has no payer")
return
}
// Reason: Force unwrapping will crash if payer is nil. Use guard for safe unwrapping.
**Category: Core Data**
**Medium Priority: ExpenseViewModel.swift:89** - Saving without checking hasChanges
// Current:
try? context.save()
// Suggested:
if context.hasChanges {
do {
try context.save()
} catch {
print("Failed to save: \(error.localizedDescription)")
}
}
// Reason: Check hasChanges to avoid unnecessary saves. Handle errors properly.
**Category: Collections**
**Low Priority: ExpenseViewModel.swift:123** - Inefficient filtering
// Current:
let found = expenses.filter { $0.id == targetId }.first
// Suggested:
let found = expenses.first { $0.id == targetId }
// Reason: first(where:) stops at first match, filter processes entire array.
📊 Code Quality Score
**Overall: 7/10**
- Swift Idioms: 6/10 (force unwrapping, inefficient collection usage)
- Architecture: 9/10 (excellent MVVM separation)
- Error Handling: 7/10 (using try? too often)
- Naming: 9/10 (clear, descriptive names)
- Organization: 8/10 (good marks, could improve grouping)
- Performance: 7/10 (some inefficient patterns)
📋 Recommendations
1. **High Priority**: Remove all force unwrapping (5 instances found)
2. **Medium Priority**: Improve error handling (don't swallow errors with try?)
3. **Low Priority**: Use first(where:) instead of filter().first
🔧 Quick Wins
1. Replace `expense.payer!` with safe unwrapping (ExpenseViewModel.swift:45)
2. Add hasChanges check before context.save() (ExpenseViewModel.swift:89)
3. Use first(where:) for finding items (ExpenseViewModel.swift:123)
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
Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
Comprehensive GitHub code review with AI-powered swarm coordination
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability, and adherence to project standards.
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
Take rshankras/coding-best-practices from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.