Chapter 2 · Gate 02
The App Environment
Before the first window appears, an app has already made its most consequential wiring decisions: who receives the platform’s lifecycle events, what gets configured in which order, where user preferences live, and how objects find their collaborators. This chapter covers that environment as a whole, then five subchapters take one piece each.
The shape of the environment
Everything starts at the platform’s edge: The App Delegate is the object the system hands its lifecycle events to, and its entire job is to translate them into the app’s own phases — never to own anything itself. What those phases are — a fixed initialization sequence, modal startup gates, restoration, launch — is Startup. One of those phases has a timing problem baked in by the platform, and Window Restoration covers the coordinator that resolves it.
The remaining two pieces outlive launch. Settings covers where user-facing configuration lives — the one model shape simple enough to be its own manager. Object Wiring covers how every object in the app reaches its collaborators — construct what you own, reach for shared when you don’t — and why there is no dependency-injection container anywhere in this architecture.
The rules that hold across all five
Launch order is enforced, not assumed. Initializers only call into the Model layer; no controller starts before phase 4; nothing shows UI before the startup gates clear. Every object downstream is written assuming the subsystems it depends on are already configured — which is only safe because the phases make it true.
The environment is ambient, not passed. Objects reach shared subsystems through flat accessors — SyncManager.shared, EditorSettings.shared — never through constructor-injected dependencies or a root service object. What varies gets configured once at launch; what doesn’t stays concrete.