Why Hostwright
Hostwright exists because of a specific change in the Mac development landscape, and because of a gap that change leaves open.
Apple container is a new runtime surface
Section titled “Apple container is a new runtime surface”For years, running Linux containers on a Mac meant a shared Linux VM managed by a third-party tool. Apple container changes the substrate: it is Mac-native, built for Apple silicon, and uses a lightweight VM per container with an OCI image flow.
A runtime is not a workflow. Apple container can start and stop containers; it does not, by itself, declare a multi-service stack, validate it, converge to it, or report drift.
Local desired-state control is the missing layer
Section titled “Local desired-state control is the missing layer”Without a control layer, a local stack is a set of imperative commands and an operator’s memory of what should be running. A desired-state layer records that model instead:
- The stack is declared once.
- Changes are planned before they run.
- Drift between declared and observed state is detected and reported.
- Cleanup is ownership-checked.
This is the layer Hostwright provides. It borrows the idea of a control loop from systems like Kubernetes without borrowing their scope.
Why single-host first
Section titled “Why single-host first”A single Mac is the environment most developers run. Building a cluster orchestrator first would spread the implementation across distributed-systems problems before the local model is complete. Single-host first bounds the scope of the first release; the identity, fencing, and recovery model is designed to extend to multiple Macs later.
Why Swift
Section titled “Why Swift”The runtime substrate is Apple-native, so the control plane is too. Swift gives Hostwright direct access to macOS facilities such as the Keychain, process control, and system SQLite, plus a native path to Apple’s Containerization APIs. A Swift daemon, CLI, and core library keep the whole system in one idiomatic, testable codebase, with no external package dependencies.
Why the RuntimeAdapter is the core boundary
Section titled “Why the RuntimeAdapter is the core boundary”Apple container is young and will change. The single most important design decision is to route every runtime operation through one typed boundary, the RuntimeAdapter, so that runtime change is contained to one place. Hostwright can start on the Apple container CLI today and move to a native API later without rewriting the reconciler, because both implement the same provider contract.
