Core Concepts

These concepts are shared across iOS, Android, and API integration.

Workout formats

WorkoutKit supports two workout formats. A classic workout is built as a sequence of sections and exercises, where effort can be expressed as duration or repetitions, and where some blocks may be optional. A video workout is a continuous streaming experience with transport controls and section metadata for timeline-aware behavior.

Session lifecycle

Every session follows the same lifecycle across platforms. Your app first discovers workouts, then selects one and fetches the corresponding session payload from GraphQL. Once the payload and WorkoutKitToken are available, the SDK UI is launched. During the workout, users progress through sections and tasks. At completion, the host app receives session state that can be persisted or forwarded to analytics pipelines.

Configuration model

Customization is provided at launch time through platform-specific configuration objects. These inputs control key text labels and behavior flags while preserving native platform conventions. Visual integration follows host app accent and theme settings to ensure the workout experience remains coherent with your product.

WorkoutKit mobile is distributed as a compiled SDK and its source code is not shared with B2B clients. Full visual customization remains possible as part of a dedicated paid customization engagement, in which case FizzUp provides a client-specific build.

Security and identity

WorkoutKit uses a bring-your-own-identity approach. Your backend remains responsible for identity and token issuance, and JWT tokens are signed with your private key. The API layer validates these tokens without requiring end users to create a separate WorkoutKit account.

For SDK launch itself, WorkoutKit also uses a second mandatory server-response authentication layer based on a device-bound WorkoutKitToken. This signature is returned alongside the session payload and should be fetched close to launch time.