iOS idioms and anti-patterns

The idioms

protocol PickerDelegate: AnyObject {        // so it can be weak
  func picker(_ p: Picker, didPick item: String)
  func pickerShouldClose(_ p: Picker) -> Bool   // answer back
}
final class Picker {
  weak var delegate: PickerDelegate?        // Picker never owns it
  func pick(_ item: String) {
    delegate?.picker(self, didPick: item)
    if delegate?.pickerShouldClose(self) ?? true { /* close */ }
  }
}
// load(true, false) -- what? Name the choice instead:
enum CachePolicy { case useCache, reload }
func load(_ policy: CachePolicy) {}         // load(.reload)

Massive VC — the recipe

Characterisation/snapshot tests first, then steps 1–6 as drawn, one safe move at a time (child VCs: addChild + didMove(toParent:)). It is an SRP problem, not an MVC one — moving the mass into the model or a Manager only relocates it.

Interview traps

• “Singletons are always bad” — no (FileManager.default). The damage is hidden lookup (.shared inside logic) + global mutable state: keep one instance, inject it.
• A service locator still hides dependencies — a missing registration fails at run time, not compile time (Mark Seemann).
• NotificationCenter for a 1:1 flow = invisible coupling: no contract, no “who listens?”.
• “Duplication is far cheaper than the wrong abstraction” (Sandi Metz).
• UIAction/sink/timer closures are stored: [weak self]; unowned only when the lifetime is guaranteed.

Remember

Answer back → delegate · one → closure · many → Combine/Notification · unknown → responder chain. Make responsibilities and dependencies visible.

Likely questions

1. Delegate vs closure? — many related callbacks + answers vs one event.
2. Why weak delegate? — the delegate usually owns the delegator.
3. Callback pyramid? — async/await, async let, task groups.