Making the Launcher Own Its Storage and Processes

A useful launcher needs to do more than start a process. It needs to know where its managed files belong, which process it owns, whether a launch is still active, and what stopping that launch actually means. Those details become especially important when the engine is running translated code and keeping several runtime components together.

The October 11 launcher work included managed-storage checks, a native process supervisor, and a shared launcher client. The shared code compiled, the full SwiftUI launcher passed typechecking, and the native control tests exercised the supervisor protocol and the package-contained development pieces.

The practical goal is to keep a launch attached to its owner. If the user closes or stops it, Ferrum should have a bounded way to finish that operation and report the result. It should also keep its own state separate from a live application library used elsewhere. Development tests use staged copies where state needs to change.

This is also where storage and packaging choices start to affect the user experience. A managed runtime should have a known location and a predictable lifecycle. A successful development run that depends on a temporary directory or a developer's existing installation isn't enough for someone installing the finished application on another Mac.

The limits are worth stating clearly. Native control tests and a typechecked GUI don't prove a complete graphical launch-and-play workflow through the newest FEX candidate. They also don't establish a signed, notarized, stapled distribution or a clean-machine installation. The development package and the final product have different acceptance requirements.

This work made the launcher side more concrete while the translation work continued. The next step is to qualify those pieces together with real application launches and the intended runtime bundle, then repeat the workflow on the required clean test machines.