Swift Code Review
Quick Reference
| Issue Type | Reference | |------------|-----------| | async/await, actors, Sendable, Task | references/concurrency.md | | @Observable, @ObservationIgnored, @Bindable | references/observable.md | | throws, Result, try?, typed throws | references/error-handling.md | | Force unwraps, retain cycles, naming | references/common-mistakes.md |
Review Checklist
- [ ] No force unwraps (
!) on runtime data (network, user input, files) - [ ] Closures stored as properties use
[weak self] - [ ] Delegate properties are
weak - [ ] Independent async operations use
async letorTaskGroup - [ ] Long-running Tasks check
Task.isCancelled - [ ] Actors have mutable state to protect (no stateless actors)
- [ ] Sendable types are truly thread-safe (beware
@unchecked) - [ ] Errors handled explicitly (no empty catch blocks)
- [ ] Custom errors conform to
LocalizedErrorwith descriptive messages - [ ] Nested @Observable objects are also marked @Observable
- [ ] @Bindable used for two-way bindings to Observable objects
When to Load References
- Reviewing async/await, actors, or TaskGroups → concurrency.md
- Reviewing @Observable or SwiftUI state → observable.md
- Reviewing error handling or throws → error-handling.md
- General Swift review → common-mistakes.md
Review Questions
- Are async operations that could run concurrently using
async let? - Could actor state change across suspension points (reentrancy bug)?
- Is
@unchecked Sendablebacked by actual synchronization? - Are errors logged and presented with helpful context?
- Could any closure or delegate create a retain cycle?