XR fitness app companion UI for iOS: the SwiftUI screens
The headset owns the immersive workout; the phone owns setup, live metrics, and history. Keeping that split clean is the whole design.
TL;DR
An XR fitness app's iOS companion is the iPhone screen that pairs with an immersive workout on a headset like Vision Pro, handling setup, live metrics, and history while the headset shows the workout itself. It is built in SwiftUI, pulls workout data through HealthKit, and stays in sync with the XR session so the phone and headset never disagree about heart rate, reps, or time. Starting from a free VP0 design and letting Claude Code or Cursor read its source page gets the screens right so you can wire the sensors and session on top.
An XR fitness app’s iOS companion is the iPhone screen that pairs with an immersive workout running on a headset like Vision Pro, handling setup, live metrics, and history while the headset shows the workout itself. The companion UI is built in SwiftUI, pulls workout data through HealthKit, and stays in sync with the XR session so the phone and the headset never disagree about heart rate, reps, or time. The companion is where the data lives and the headset is where the experience lives, and getting that split right is the whole design. The fastest way to get the screens looking right is to start from a free VP0 design and let Claude Code or Cursor read its source page, then wire the sensors and session on top.
A fitness companion is glanceable by nature: a user mid-workout, or someone checking in on a phone while wearing a headset, has seconds to read it. The sections below cover the screens, the live data, the connection to the XR session, and the mistakes that make a companion feel disconnected.
What does an XR fitness companion app’s iOS UI do?
It handles everything around the immersive workout that is easier on a phone than in a headset: choosing a session, seeing live metrics, reviewing a summary, and browsing history. The headset is great for the workout itself, but typing, scrolling history, and checking detailed stats are far more comfortable on iOS, so the companion takes those jobs. It also acts as the record, writing completed workouts to HealthKit so they appear in the Health app alongside everything else.
The design principle is a clean division: the headset owns the in-the-moment experience, and the phone owns setup, data, and history. When the two blur, you end up duplicating controls awkwardly in both places. Keeping the companion focused on what a phone does best is what makes the pair feel intentional. Related immersive patterns are covered in Apple Vision Pro XR components.
The companion screens you need
A fitness companion comes down to four screens, each doing one job. Designing all four, rather than only the live view, is what makes it feel complete.
- Connect and setup, where the phone pairs with the headset session and the user picks a workout, with a clear connected or disconnected state.
- Live session, the glanceable view of heart rate, time, reps or distance, and calories while the workout runs.
- Summary, shown right after a workout, with the key numbers and a save-to-Health action.
- History, the scrollable record of past workouts with trends over time.
The live session screen carries the most weight, so make its numbers large and readable at a glance, since a user may check it mid-movement. The history screen is where a phone genuinely beats a headset, so let it be richer. A glanceable metric layout like the HealthKit step counter template shows the live-number treatment that works here.
Live metrics from HealthKit and sensors
The live numbers come from HealthKit and the device sensors, not from your own counters. You start a workout session, and HealthKit streams heart rate, active energy, and other metrics, often sourced from an Apple Watch the user is wearing, which is the most accurate heart-rate source available. Reading from HealthKit rather than estimating means the companion agrees with the Health app and the user’s other fitness data.
The flow is to request authorization for the workout types you need, explaining why, start the session when the workout begins, and update the live screen as samples arrive. Two rules keep it honest. Ask only for the data you use, since health permissions are sensitive, and handle the case where the user declines, so the companion still works with whatever it is allowed to read. Writing the completed workout back to HealthKit at the end is what makes it count toward the user’s rings and history. A timer-and-rings pattern like the intermittent fasting timer ring shows the same HealthKit-backed live display.
Connecting the phone to the XR session
The trickiest part is keeping the phone and the headset in sync. The companion needs to know the workout has started, update as it progresses, and reflect when it ends, which means a live link between the two devices. Depending on the design, that is a local connection over the same network, a handoff through the user’s account in the cloud, or a shared session, but in every case the phone is reflecting the headset’s truth, not driving its own.
The headset side runs the immersive experience with RealityKit and tracking from ARKit, and the companion subscribes to its state. The detail that matters is handling disconnection: if the link drops, the companion should show a clear reconnecting state rather than freezing on stale numbers, because a fitness app that silently shows old data is worse than one that admits it lost the connection. Design the connected, reconnecting, and ended states deliberately, not just the happy path where everything stays linked.
Making it native with AI and a real design
AI builders produce the companion screens quickly and miss the cross-device and sensor details. Claude Code and Cursor will lay out a live metrics view, but they tend to estimate values instead of reading HealthKit, skip the disconnected and reconnecting states, and size the live numbers like body text rather than the large glanceable figures a workout needs. The screens look right and behave like a generic dashboard.
A real design plus sensor-aware rules fixes most of it. When the four screens, the live-number sizing, and the connection states are already decided, the model builds a real companion instead of a dashboard, and you wire HealthKit and the session link yourself. Starting from a free VP0 design gives that structure, since each design has a machine-readable source page Claude Code, Cursor, or Rork read from a pasted link. The spatial-tracking side, when you need AR awareness on the phone too, carries over from the AR object placement target UI.
Common XR fitness companion mistakes
A few mistakes recur. Estimating metrics instead of reading HealthKit is the first, which makes the companion disagree with the Health app and the user’s Watch. Skipping the disconnected and reconnecting states is the second, so the phone freezes on stale numbers when the link to the headset drops, which is the worst failure for a fitness app.
Sizing live numbers like normal text is the third, since a mid-workout glance needs large, instantly readable figures. Duplicating the headset’s controls awkwardly on the phone is the fourth, which blurs the clean split between the two devices. The fifth is forgetting to write the workout back to HealthKit, so the session never counts toward the user’s rings and history. Reading from HealthKit, designing the connection states, and keeping the companion focused on setup, glanceable metrics, and history are what make the pair feel like one product.
Accessibility and honest health framing
A fitness companion handles health data and is used in motion, so accessibility and honest framing are not optional. The large live numbers should still be readable when a user turns up Dynamic Type, and they should be announced to VoiceOver with their unit, so “142 beats per minute” is spoken rather than a bare number. Do not rely on color alone to signal a heart-rate zone; pair it with a label or a shape, since a glance during exercise is exactly when color-only cues fail.
The framing of the numbers matters too. Heart rate and calorie estimates from sensors are estimates, not medical readings, so the copy should present them as guidance, and the app should not make health claims it cannot back. For anyone with a medical condition, the right move is to point them to a professional rather than implying the app is a diagnostic tool. Building this honesty in from the start keeps the companion both usable and responsible.
When you do not need a companion
Not every XR fitness app needs a phone companion. If the workout is fully self-contained in the headset and the user never needs to set up, review history, or check detailed stats outside it, a companion adds work for little gain. The companion earns its place when there is real value in doing something on the phone, comfortable setup, rich history, or sharing, that the headset handles poorly.
For a simple, single-session experience, the headset alone may be enough, and a companion is overbuilt. The honest call is to add the companion when the phone genuinely does a job better than the headset, not because a paired app sounds more complete. Match it to whether the user actually needs the phone in the loop.
Key takeaways: an XR fitness companion that feels connected
Build the companion around four screens, connect and setup, live session, summary, and history, and keep the headset for the immersive workout while the phone handles setup, data, and history. Read live metrics from HealthKit rather than estimating, size the live numbers large for a mid-workout glance, and design the connected, reconnecting, and ended states so the phone never shows stale data. Write completed workouts back to HealthKit so they count. Let an AI builder build the screens from a real design, then wire the sensors and session yourself. A commissioned cross-device feature can cost $5,000 or more, while starting from a free VP0 design gives you the layout for nothing.
You can browse VP0 designs to start your companion from a real layout rather than a blank screen.
Frequently asked questions
What is an XR fitness app’s iOS companion?
It is the iPhone app that pairs with an immersive workout running on a headset like Vision Pro, handling setup, live metrics, summary, and history while the headset shows the workout itself. The companion is built in SwiftUI, reads live data from HealthKit, and stays in sync with the XR session. The headset owns the in-the-moment experience and the phone owns setup, data, and history, and keeping that split clean is the core of the design. Starting from a free VP0 design gets the screens right so you focus on the sensors and session.
How does the companion get live workout metrics?
Through HealthKit and the device sensors, not your own counters. You start a workout session, request authorization for the metrics you need, and HealthKit streams heart rate, active energy, and more, often from an Apple Watch the user is wearing, which is the most accurate heart-rate source. Reading from HealthKit means the companion agrees with the Health app, and writing the completed workout back at the end makes it count toward the user’s rings and history.
How do the phone and the headset stay in sync?
The companion reflects the headset’s state over a live link, which can be a local network connection, a cloud handoff through the user’s account, or a shared session, but in every case the phone reflects the headset’s truth rather than driving its own. The detail that matters most is handling disconnection: show a clear reconnecting state rather than freezing on stale numbers, since a fitness app that silently shows old data is worse than one that admits it lost the link.
Can VP0 provide a free SwiftUI template for a fitness companion?
Yes. VP0 is a free iOS app design library where every design has a machine-readable source page an AI builder reads from a pasted link, with SwiftUI and React Native variants. You start from the companion design, with its live-metric layout and connection states already decided, hand its source to Claude Code, Cursor, or Rork, and wire HealthKit and the XR session on top, rather than building the screens and their states from scratch.
What common errors happen when building an XR fitness companion?
The frequent ones are estimating metrics instead of reading HealthKit so the companion disagrees with the Health app, skipping the disconnected and reconnecting states so the phone freezes on stale data, sizing live numbers like body text instead of large glanceable figures, duplicating headset controls awkwardly on the phone, and forgetting to write workouts back to HealthKit. The fixes are HealthKit as the source of truth, deliberate connection states, large live numbers, a clean device split, and saving completed workouts.
Other questions VP0 users ask
What is an XR fitness app's iOS companion?
It is the iPhone app that pairs with an immersive workout running on a headset like Vision Pro, handling setup, live metrics, summary, and history while the headset shows the workout itself. The companion is built in SwiftUI, reads live data from HealthKit, and stays in sync with the XR session. The headset owns the in-the-moment experience and the phone owns setup, data, and history, and keeping that split clean is the core of the design. Starting from a free VP0 design gets the screens right so you focus on the sensors and session.
How does the companion get live workout metrics?
Through HealthKit and the device sensors, not your own counters. You start a workout session, request authorization for the metrics you need, and HealthKit streams heart rate, active energy, and more, often from an Apple Watch the user is wearing, which is the most accurate heart-rate source. Reading from HealthKit means the companion agrees with the Health app, and writing the completed workout back at the end makes it count toward the user's rings and history.
How do the phone and the headset stay in sync?
The companion reflects the headset's state over a live link, which can be a local network connection, a cloud handoff through the user's account, or a shared session, but in every case the phone reflects the headset's truth rather than driving its own. The detail that matters most is handling disconnection: show a clear reconnecting state rather than freezing on stale numbers, since a fitness app that silently shows old data is worse than one that admits it lost the link.
Can VP0 provide a free SwiftUI template for a fitness companion?
Yes. VP0 is a free iOS app design library where every design has a machine-readable source page an AI builder reads from a pasted link, with SwiftUI and React Native variants. You start from the companion design, with its live-metric layout and connection states already decided, hand its source to Claude Code, Cursor, or Rork, and wire HealthKit and the XR session on top, rather than building the screens and their states from scratch.
What common errors happen when building an XR fitness companion?
The frequent ones are estimating metrics instead of reading HealthKit so the companion disagrees with the Health app, skipping the disconnected and reconnecting states so the phone freezes on stale data, sizing live numbers like body text instead of large glanceable figures, duplicating headset controls awkwardly on the phone, and forgetting to write workouts back to HealthKit. The fixes are HealthKit as the source of truth, deliberate connection states, large live numbers, a clean device split, and saving completed workouts.
Part of the Native Hardware, Sensors & Device Features hub. Browse all VP0 topics →
Keep reading
Apple HealthKit Step Counter in SwiftUI (Free Template)
Build a step-counter UI on HealthKit in SwiftUI: permission, today's steps, a trend chart, and goals, from a free VP0 design. Private, and not medical.
Biological Age Calculator Dashboard UI for iOS: Honest
Design a biological age dashboard: the estimate framed honestly, trends over absolutes, factor breakdowns tied to evidence, and zero longevity fear-mongering.
Apple HealthKit Intermittent Fasting Timer Ring in SwiftUI
A date-anchored ring that times the window honestly: TimelineView and trimmed circles, HealthKit correlation without a fasting type, and guardrails as features.
Macronutrient Barcode Scanner with Pie Chart UI
Scan is the cheap step. The work is the food database, the per-100g-to-portion math, and a macro pie that is honest about parts of a whole.
CGM Glucose Chart UI in SwiftUI: Companion-App Rules
Build a CGM glucose chart in SwiftUI: target-range bands, time-in-range as the headline, honest sensor lag, tiered alerts, and the medical-device line.
Camera Live Object Detection: The Bounding Box UI
Drawing live bounding boxes over a camera feed is mostly coordinate math. Here is how to map Vision results to view space and keep the overlay smooth on iOS.