Latency turns a class into a broadcast
Participants need to feel the instructor is leading now. Beyond a certain delay, the social contract of a live class quietly breaks.
FIELD NOTES / FITNESS TECHNOLOGY
The class is live.
The recording cannot wait for it.
FitFusion combines instructor-led live classes, real-time participant interaction, automatic session recording and Apple Watch biometrics into one workout — with the media path deliberately separated from the application path.
FITNESS TECHNOLOGY CASE STUDY
FitFusion
Live classes and wearables.
Recording on its own path.
FitFusion / Connected workoutACTUAL PRODUCT INTERFACE
THE MEDIA PLANEVideo does not travel through the application.
The backend decides who the user is and which class they may enter. Authorized clients then connect to the managed real-time environment directly, rather than routing live video through application servers.
Follow a session ↗JoinAuthorizeStreamCaptureReplay
DOMAIN
Fitness technology / digital wellness
WHAT WE BUILT
Live class platform with wearable biometrics
OUR ROLE
Mobile, wearable and real-time architecture
01 / THE REMOTE WORKOUT GAP
A recording is flexible.
It is not a class.
Pre-recorded workout libraries offer flexibility, but they lack the accountability, immediacy and community of attending a live class.
Recreating that means a remote participant has to feel an instructor is genuinely leading the session in real time. Excessive latency, unstable connections or disconnected interaction quickly turn a live workout into a delayed broadcast.
And a live session should keep earning after it ends — which makes recording a workflow problem, not a button.
Recording cannot block the participant
A live workout should continue generating value once the session ends — so recording has to happen automatically and hand off to processing without anyone waiting on media.
Biometrics matter during the effort
Heart rate, calories and elapsed time are most useful mid-exercise. Capturing them from Apple Watch and HealthKit has to avoid excessive networking and wearable battery drain.
02 / INSIDE THE PRODUCT
Join the class.
Wear the sensor.
Four views of the delivered mobile and wearable experience.
Each shows another part of a live session and what it leaves behind.
A low-latency room, not a stream.
Participants join scheduled classes through a real-time video environment, with short-lived session credentials issued after the backend has validated that they are authorized to enter.
SCHEDULED CLASS TO REPLAY
Browse→Enrol→Authorize→Join→Capture→Finish→Replay
03 / TWO PLANES, NOT ONE PIPELINE
The application decides access.
The media layer moves video.
The backend determines who the user is and which class they may enter, then issues short-lived credentials. Authorized clients connect to the managed real-time environment directly, so live video never travels through application servers.
That separation is what lets recording and replay proceed on their own schedule: processing continues asynchronously after a class ends, and the session becomes replay content once it is done — without the live path having to stay healthy for it to succeed.
Look under the hood ↘01
Access is decided before the room
Authorization happens in the application plane, and the participant receives short-lived credentials rather than a permanent key to the media environment.
Live and recording in parallel
Participants stream and interact while the session is captured on the media plane, with neither path depending on the other's throughput.
The recording still completes
Because capture does not run through the application path, a degraded or reconnecting live experience does not take the replay down with it.
02
Recording is automatic and asynchronous
Live classes are recorded without instructor action, and processing continues after the session finishes rather than holding anyone up.
03
Wearable data is sampled, not streamed
Biometrics are captured on the Watch and selectively synchronized to the phone, keeping networking and battery cost proportionate to the value of the metric.
04 / THE TECHNOLOGY & THE REASON
Managed where it is hard.
Native where it must be.
Two decisions carry the stack: real-time media is a specialism worth buying rather than operating, and wearable health data is a place where a cross-platform abstraction costs more than it saves.
MOBILE APPLICATION
React Native
The shared participant experience — browsing, enrolment, joining a session and in-class interaction.
Why cross-platform here?
Shared mobile workflows benefit from one codebase, while the Apple-specific wearable and health work stays native rather than being forced through an abstraction.
APPLICATION CONTRACTS
TypeScript
Typed contracts across the mobile application, keeping session, class and participant shapes explicit.
Why typed?
Session state moves between the application plane, the media layer and the wearable. Ambiguity about its shape is where multi-device products break.
LIVE MEDIA
Agora RTC
The low-latency media layer for instructor-led sessions, joined directly by authorized clients rather than proxied through application servers.
Why a managed provider?
Globally distributed RTC involves networking, codec, NAT traversal and scaling concerns. Buying that lets the team spend its effort on the fitness product and its access rules.
PARTICIPANT MESSAGING
Agora RTM
A dedicated real-time path for the short messages and reactions exchanged during a class.
Why separate from video?
Interaction has to stay responsive enough to feel social while remaining light enough that people can keep exercising through it.
WEARABLE COMPANION
Swift + SwiftUI
The Apple Watch application, scoped to glanceable workout data and native device capability.
Why native on the Watch?
The wearable is not a small phone. Its value is immediate physical feedback, which needs the platform's own APIs rather than a port of the mobile UI.
BIOMETRIC CAPTURE
HealthKit
Access to Apple-platform workout and biometric information — heart rate and calorie data used by the wearable experience.
Why the platform API?
Native health APIs are the supported path to Apple Watch fitness data, and a cross-platform framework alone is not sufficient for every wearable workflow.
The confirmed product foundation is the React Native mobile application, the Apple Watch companion with HealthKit integration, Agora-powered live video and messaging, and automatic session recording. The source additionally describes web, TV, backend topology and AWS infrastructure as a production-grade extension of that foundation; those surfaces are not claimed here.
Explore the documented platform stack
- Mobile
- React Native · TypeScript · participant experience
- Wearable
- Swift · SwiftUI · Apple Watch companion
- Health data
- HealthKit · heart rate · calories · workout state
- Live media
- Agora RTC · low-latency instructor sessions
- Messaging
- Agora RTM · in-class participant interaction
- Recording
- Automatic session capture · asynchronous processing to replay
Technology names identify the documented implementation, not partnerships or endorsements.
A CONVERSATION ABOUT YOUR LIVE PLATFORM
What breaks when the
live session degrades?
Bring one real-time experience where something valuable has to survive the session — a recording, a transcript, a set of metrics. In 30 minutes, we will look at which planes your product has, and which of them are currently load-bearing for each other.
30 minutes · Your live experience and what it leaves behind