iOS Review

Current diff (when reviewing a PR)

Get the diff between this branch and its parent branch (NOT always main). If this has no parent branch, stop.

iOS Code Review — Team Conventions

Review the code (or the diff above if present) against the rules below. Apply General Rules always. Apply UI Rules only if the changes include SwiftUI views (files containing View, body, @ViewBuilder, or SwiftUI imports).

For each violation, report:

• Rule: which rule was broken
• Location: file + line number
• Suggestion: concrete fix

If no violations are found, say so clearly.

---

Authoritative Style Guides

Apply these guides in full during every review:

1. Swift API Design Guidelines — naming, documentation, Boolean assertions, protocol suffixes, factory method prefixes, mutating/nonmutating pairs, parameter ordering.
2. Google Swift Style Guide — formatting, brace style, import ordering, enum layout, trailing closures, trailing commas, /// documentation format.

The team rules below are additions or overrides to those guides. Do not re-report violations already covered by the guides unless a rule here applies a stricter standard.

---

General Rules

1. Avoid 2+ depth nested conditionals

Nested conditionals (if, guard, switch, for, while, repeat) at a depth greater than 2 (more than one conditional inside another) are a bad pattern. Prefer:

• guard/else to exit early instead of nesting
• Extracting conditions into well-named boolean variables or functions
• AI-assisted rewrites when nesting is deep

Flag any conditional nested inside another at a depth greater than 2, OR with unnecessary nesting that could be chained.

Why: Deep nesting hides the happy path, increases cognitive load, and makes it easy to miss edge cases. Early exits keep logic linear and readable.

2. Use async/await instead of callbacks

All async code should use Swift's async/await. Callbacks (completion handlers, closures passed as the last argument to async operations) are the old pattern and should not appear in new code.

Why: Callbacks invert control flow and make error handling inconsistent. async/await reads top-to-bottom, composes cleanly with try, and eliminates callback pyramids.

3. Name functions after intent, not implementation

Function names should describe what the function achieves, not how it works. For example, a function that registers a hook to make an interaction fail should be called failInteraction(), not registerFailureHook().

Also: add comments on functions you cannot rename (e.g. protocol requirements, library callbacks) explaining their intent.

Why: Implementation details change; intent rarely does. Names tied to mechanics rot as the code evolves and obscure the purpose at the call site.

4. Public methods before private methods

public and open methods should appear near the top of a type, just below init.

Correct order within a type:

1. init
2. public/open methods
3. internal methods
4. private methods

Why: Public APIs are hard to change post-release. Placing them at the top makes the contract immediately visible to reviewers without scrolling past implementation details.