Poking around the visionOS SDK

Following the release of the very first seed of the Software Development Kit for visionOS, here’s a gathering of a few things I’ve found while quickly poking around the visionOS 1.0 Beta SDK, based on my understandings of how Apple’s systems are developed and work.

TL;DR: what’s below may be inaccurate, misworded or blatantly wrong. Don’t hesitate to correct me.

Software

Based on iOS

The Simulator Runtime (and the recoveryOS build for the headset) makes it pretty clear: visionOS was named xrOS during development and is based on iOS.

Unlike iPhone OS, based on CoreOS components (think XNU and launchd) borrowed from Darwin and Mac OS X to form a new operating system of its own, visionOS is iOS but from another build train, like watchOS (for Apple Watch), tvOS (for Apple TV/HomePod), bridgeOS (for T1/T2 Security chips), darwinOS (for Apple Studio Display) and recoveryOS (standalone wireless recovery environment for at least Apple Watch and Apple TV).

visionOS 1.0 Beta has the build number 21N5165g. Let’s dive into it:

21N5165g¹

21N is the build train identifier, named Borealis. iOS 17’s build train identifier is 21A (named Dawn), indicating that visionOS 1.0 is based on iOS 17.0;
5 is the build variant. 5 means it’s a Beta build. Those builds are from dedicated build trains with the “Seed” suffix (visionOS 1.0 Beta is BorealisSeed and iOS 17.0 Beta is DawnSeed). Internal development happens in non-Seed build trains and only stuff that’s been announced goes to Seed builds for distribution outside Apple to developers, AppleSeed members and public beta testers;
165 is the increment number. visionOS 1.0 Beta has been compiled 164 times before this build. Newer builds have a higher increment.

This isn’t a new approach: watchOS, tvOS, bridgeOS, darwinOS and recoveryOS are all developed the same way: derived from iOS and including device-specific software and firmware when building, like Carousel.app for watchOS and HeadBoard.app for tvOS (more on that later).

iOS became the AppleOS that gets forked whenever a new product category comes out, with macOS being the caring grandfather that oversees it all.

Because visionOS is from iOS, it shares its CoreOS foundations with the rest of the family: XNU says hello, launchd is there, daemons are more or less the same and usual frameworks (public and private) are present as well.

Dedicated GUI

Unlike Mac OS X which had several processes in charge of the GUI (WindowServer, LoginWindow, Finder.app, Dock.app), iPhone OS had one: SpringBoard.app.
Each iOS derivative has its own “Home Screen” app: watchOS has Carousel.app, tvOS has HeadBoard.app.

For visionOS, Apple made SurfBoard.app. Located at the usual place (/System/Library/CoreServices/SurfBoard.app), it is launched at boot by launchd as the “EmbeddedHomeScreen” process running with the mobile user privileges, present since iPhone OS 2 (in iPhone OS 1, SpringBoard.app was running with root privileges. Not a good security practice).

Interestingly, SurfBoard.app‘s main executable, SurfBoard, is just a wrapper. All the logic is in the SurfBoardFramework dynamic library in SurfBoardFramework.framework, located inside the app bundle and not in /System/Library/PrivateFrameworks/.

As a replacement to SpringBoard.app, SurfBoard.app handles the usual Mach services that are usually devoted to SpringBoard.app, like PurpleSystemAppPort. It also listens on new Mach ports for what I call the “Reality subsystem”, like com.apple.realitysystemsupport.hid_server or com.apple.surfboard.launcherservice.

Unlike SpringBoard.app which was a monolith for years, SurfBoard.app delegates a lot of UI tasks to other “Reality subsystem” apps and bundles, with self-explanatory names:

/Applications/RealityBreakthrough.app
/Applications/RealityChrome.app
/Applications/RealityControlCenter.app
/Applications/RealityCoverSheet.app
/Applications/RealityEnvironment.app
/Applications/RealityGuestSetup.app
/Applications/RealityHUD.app
/Applications/RealityKeyboard.app
/Applications/RealityLauncher.app
/Applications/RealityNotifications.app
/System/Library/HUDItems/Bundles/ControlCenterHUDItem.bundle
/System/Library/HUDItems/Bundles/EnvironmentHUDItem.bundle
/System/Library/HUDItems/Bundles/HomeHUDItem.bundle
/System/Library/HUDItems/Bundles/NotificationCenterHUDItem.bundle
/System/Library/HUDItems/Bundles/SearchHUDItemProvider.bundle
/System/Library/HUDItems/Bundles/SiriHUD.bundle

And a daemon called wakeboardd handles compositing:

All right, what I learned so far from visionOS:
– Compositor is implemented in /usr/libexec/wakeboardd
– layers are created here
– rt_sim_hmd_composite composites these layers with Metal
– I haven't figured out how to make it do 3D/stereo yet
– I'm not as smart as ShinyQuagsire
— Zhuowei Zhang (@zhuowei) June 22, 2023

Also present a lot are “Muse“, “Wolf” and “TDG” (for Technology Development Group) prefixed bits.

Wolf was reported to be the whole xrOS platform codename (like Aspen was to iPhone OS), and based on bundles and frameworks like MediaControlsModuleWolf.bundle and FaceTimeSupportWolf.framework, this is clearly the case.

My guess: these prefixes (along with the N301 and xrOS suffixes, more on that later) were used to strip visionOS and Vision Pro-related bits for builds seeded to people who were unaware of the Vision Pro’s existence, and outside Apple.

For instance, Setup.app (codenamed PurpleBuddy) is replaced by MuseBuddyApp.app. Since Purple was the codename of the iPhone project, it was only fitting that its replacement should bear a visionOS codename (and the bundle identifier is com.apple.tdg.systemapps.MuseBuddyApp. 2-in-1).

Another example: visionOS-specific Control Center modules are in the /System/Library/ControlCenter/Bundles/Muse/ directory (ModuleAllowedList.plist acts as a whitelist of modules that can be loaded by Control Center, referencing an internal module identified by com.apple.TDGPerfTools.controlcenter.PerformanceTraceModule).

Hardware

Board

The board config number is N301AP, confirming that the rumors around the N301 codename were true.

Model number

The RegulatoryInfo image file seems to indicate that Apple Vision Pro will have the model number A2117.

Model identifier

The model identifier is RealityDevice14,1. My guess: Apple uses their new naming scheme: [ProductType][SoC],[X].

For instance, (some) Macs with M1 are Mac13,x and all Macs with M2 are Mac14,x. Since Apple Vision Pro is built around the M2 SoC, it makes sense that the base model identifier is RealityDevice14,x.

Limitations of visionOS 1.0 Beta / Apple Vision Pro dev kits

In the visionOS 1.0 Beta Release Notes, and in a typical Apple fashion when it comes to writing release notes for Developer seeds, there are a few elements about the visionOS 1.0 Beta (not the SDK) and Apple Vision Pro:

“visionOS automatically checks if display adjustment is required the first time you put on Apple Vision Pro. Press and hold the Digital Crown until you see a green check mark. If you’re unable to complete adjustment, contact your WWDR representative.[…]”
“To Force Quit an app, hold both the Digital Crown and top button for 2 seconds. Select the desired app from the list which appears, then select the Force Quit button.”
“Ensure only one prescription ACC is visible during prescription lens enrollment. If the enrolled prescription doesn’t match, delete the enrollment and re-enroll.”
“Optic ID is limited to two Rx enrollments and one non-Rx enrollment.”
“Selecting incorrect Zeiss Optical Inserts might cause eye enrollment to fail.”
“Travel Mode is optimized for a stationary experience. If you activate Travel Mode in Control Center and start walking, you might experience unexpected behavior.”

Final word

Kudos to the Technology Development Group and all the involved Apple folks! I suppose that finally showing this to the entire world has to be an exhilarating feeling and it’s a wonderful new platform you’re putting out here. Can’t wait to get my hands on a Vision Pro when it’ll be available in France one day.

¹ I’ve still not figured out what appended letters (g in this case) mean. Any ideas?