Battery, sound, brightness, and the rest
A desktop expects the hardware a Linux box would have: a battery, speakers, a brightness slider, Bluetooth, a keyboard, orientation. iOS exposes all of it, just not the way Linux looks for it. A set of small daemons translate each one.
The pattern
Every integration is a small daemon that owns the interface the desktop already expects, a D-Bus service, a Wayland protocol, or a file under /sys, and answers it with the matching iOS API. The iOS side is reached with dlopen and the Objective-C runtime, so nothing links a private framework at build time and every probe degrades cleanly when the API is missing. It is the same shim trick behind the logind, polkit, and Accounts stubs that let GNOME start.
Audio
xios-audiod opens a CoreAudio RemoteIO output under an AVAudioSession set to the Playback category, so sound keeps going through the mute switch and the lock screen. Apps never talk to it directly. PulseAudio modules present an ordinary sink and microphone source, xios and xios_mic, so GTK, gvc, and PulseAudio clients route through the native daemons.
Brightness and battery
xios-hwbridged reads the battery with IOKit's IOPSCopyPowerSourcesInfo and the screen brightness with BackBoardServices' BKSDisplayBrightnessGetCurrent and Set, both dlopen'd. It republishes the battery as UPower, so the shell shows a real charge level, and backs the brightness slider with a org.gnome.SettingsDaemon.Power.Screen shim plus a synthetic /var/jb/sys/class/backlight, so moving the slider dims the actual display.
Bluetooth
GNOME's Bluetooth panel and quick toggle expect BlueZ on D-Bus, which iOS does not have. xios-bluez-stub owns org.bluez and answers the slice gnome-bluetooth actually uses, adapters and devices, power and scan state. Connect and disconnect support is still being brought up against iOS's private BluetoothManager framework.
Keyboard, orientation, and feel
The keyboard is the neat one. When a Wayland app focuses a text field it enables the text-input-v3 protocol; iosc sees that enable and treats it as the cue to raise the iOS on-screen keyboard, then dismisses it when the field loses focus. The same protocol carries the field's traits, so an email field gets the email keyboard and a search box gets a Search return key, and what you type comes back as text-input commits rather than a faked hardware keyboard. That whole path is xios-osk.
The rest ride smaller bridges. CoreMotion feeds a SensorProxy-compatible shim, and xios-sysintd wires the hardware volume buttons to pactl, the system light and dark setting to the GNOME color scheme, and device rotation to a live iosc resize. It also carries haptic requests toward UIFeedbackGenerator while the physical feel is still being tuned.
The iosc shell's own top bar skips D-Bus entirely and reads the device directly: battery from IOKit, Wi-Fi and cellular from SystemConfiguration reachability, and the device name from MobileGestalt.