The View Layer

Views read from the Model. This chapter introduces the read/render side of the architecture — how a SwiftUI view hosted inside AppKit stays reactive, how a view controller assembles and scopes that hierarchy, the activation lifecycle that drives it, and the menus that are themselves just another view component — and lays out how the four relate before four subchapters go deeper on each.

The shape of the layer

A SwiftUI view hosted inside AppKit is deliberately dumb: given state, it draws it and emits intents through closures. Views covers that split in full — the three-layer shape every piece of UI follows, and the one rule that keeps a hosted SwiftUI view reactive instead of silently going stale.

Something still has to assemble those views into a hierarchy and scope them into coherent, independently testable pieces. View Controllers covers that — the four jobs a view controller does, and when a piece of UI has earned a view controller of its own rather than staying embedded in its parent’s.

Views and their AppKit controllers lean on observeState() and activateObservation() without fully explaining them. State Observing covers the activation lifecycle underneath — subscribing, seeding, and tracking in one auditable method — worked through as a view controller, a self-rendering view, and a container that activates a whole subtree of subcontrollers at once.

A menu isn’t a special case bolted onto the architecture — it’s the mutate path wearing an NSMenuItem. Menus covers building menus as view components wired to Actions, carrying typed data on them safely, and getting validation for free.

The rule that holds across all four