People ask in nearly every intro conversation: what does "System UI" actually mean? The shape of the answer matters more than the inventory. The visionOS System UI team owned the surfaces every visionOS app and the operating system itself rendered against — window chrome, ornaments, alerts, status, lock screen, notifications, and the input pipeline that fed them.
The constraint was unusual. A platform with no installed base, no precedent for legible 3-D windows, and a hard launch date. The chrome had to feel inevitable on day one and survive third-party apps on day two.
Hold the surface count small. Treat every chrome as a single rendering pipeline.
Surface count is a feature
Every surface we added was a thing we had to maintain, calibrate, and explain to every team that built against the platform. The forcing function was simple: if a new chrome couldn't earn its place against the existing list, it didn't ship.
Hiring against the work
We grew the org from three engineers to roughly thirty across three calibration cycles. The discipline was hiring against the surfaces, not the headcount. Each new hire owned a piece of the chrome end-to-end — and that ownership is what kept the review bar from drifting as the team grew.
What it looked like at the end
By visionOS 1.1 the chrome had three concurrent ship trains running, six patents granted or filed against the work, and a hiring funnel that ran continuously for eighteen months. The surfaces shipped, the team shipped, and the launch landed.