Cheat Sheets

Dispatch (Swift) 1. What is it? Dispatch is the mechanism that decides which implementation a call will execute (and when that decision is made: compile-time vs runtime). In Swift, dispatch choices directly affect polymorphism, correctness (especially with protocol extensions), and performance. 2. What problem does it solve? Enables polymorphism (same call, different behavior) via inheritance or protocols. Balances flexibility vs performance (dynamic lookup vs direct calls). Defines how overrides, protocol conformances, and runtime features (KVO/swizzling) work. 3. Types / Categories Kind Trigger / Where it appears Mechanism Typical cost Notes Static dispatch (direct call) struct/enum, final methods/classes, static functions, many generics Compiler emits a direct call Lowest Most optimizable (inline, specialize) Virtual dispatch (vtable) class inheritance + overridable methods vtable lookup Low–medium Enables override polymorphism Protocol dispatch (witness table) Calling protocol requirements through a protocol type witness table lookup Low–medium Key for any Protocol calls Obj-C message dispatch @objc dynamic, KVC/KVO, swizzling, selectors objc_msgSend Medium–high Most dynamic, least optimizable 4. How does it work in Swift? Quick decision tree Value types (struct/enum) → usually static dispatch final class or final func → static dispatch (cannot be overridden) Non-final class methods (especially overridden) → vtable dispatch Protocol requirement calls via any Protocol → witness table dispatch Protocol extension methods → static dispatch (common footgun) Generic T: Protocol → often specialized by the compiler → can become close to static dispatch @objc dynamic → Objective-C runtime dispatch (objc_msgSend) Why protocol extensions can surprise you A method implemented in a protocol extension is not always dispatched through the witness table. If you call it via an existential (let x: any P = ...), Swift may bind to the extension implementation (static) instead of the conforming type’s method (dynamic through witness table). Rule of thumb: ...

Cheat Sheets All cheat sheets follow a strict, shared structure. Each document is designed for quick recall rather than full tutorials. If you are adding a new cheat sheet: Use the template in cheat-sheets/_template.md Keep it under 1–2 screens Focus on “why” and “when”, not syntax

some vs any (Opaque vs Existential) 1. What is it? some defines an opaque type: the concrete type is fixed but hidden from the caller. any defines an existential type: the concrete type is erased and can vary at runtime. 2. What problem does it solve? They let APIs abstract over types: some: abstraction without losing static type information any: abstraction when heterogeneity or runtime flexibility is required 3. Types / Categories Opaque types (some P) Compile-time concrete type Single underlying type per declaration Existential types (any P) Runtime type-erased container Can hold multiple concrete types over time 4. How does it work in Swift? some P Compiler generates a hidden concrete generic Uses static dispatch, specialization, and inlining Backed by vtables/witness tables known at compile time any P Stored as an existential container Uses dynamic dispatch via witness tables May allocate (inline buffer vs heap) depending on size 5. Dangerous corners / Footguns some cannot return different concrete types across branches any loses associated type and Self information Existentials inhibit specialization and inlining Existential boxing can cause unexpected heap allocations Mixing any P with generics often causes silent performance cliffs 6. When should I use which? Use some when: You control the implementation You want abstraction and performance The concrete type is stable per API Use any when: You need heterogenous collections The concrete type varies at runtime API boundaries require type erasure Prefer generics over any when the caller can benefit from specialization 7. 30-second summary some = hidden concrete type, fast, statically dispatched any = type-erased container, flexible, dynamically dispatched some preserves optimization; any trades performance for flexibility Default to some (or generics); reach for any only when necessary

SwiftUI View Identity & Lifetime What is it? SwiftUI’s model where View values are cheap, ephemeral structs, while identity determines which underlying persistent backing store (state, subscriptions, render resources) is reused across updates. “Lifetime” is mostly about the lifetime of that backing store, not the View value. What problem does it solve? Enables a pure(ish) declarative UI where the framework can diff successive body results and update only what changed, while preserving state for “the same” conceptual view across recomputations. ...