Skip to main content

Overview

This guide walks you through the complete integration of the Open Wearables iOS SDK into a native Swift application, from backend setup to production deployment.
1

Set up backend authentication endpoint

2

Configure the SDK in your iOS app

3

Implement sign-in flow

4

Request health permissions

5

Start background sync

Read the Mobile SDK Integration Guide first. It covers what is the same on every platform: authentication, the backend token endpoint, the SDK lifecycle, and the production checklist. This page shows the Swift code for each step.

Step 1: Backend Setup

Your backend exchanges your app credentials for user-scoped SDK tokens and forwards them to the app - the app never sees app_id / app_secret. See Backend Endpoint for the setup and example code.

Step 2: SDK Configuration

Configure the SDK once at app startup, typically in your AppDelegate or app initialization code.

Configuration Options

Provide only the base host URL, e.g. https://your-domain.com. Do not append /api/v1/ or any other path — the SDK adds the required path prefix automatically.

Session Restoration

The SDK automatically persists credentials in the iOS Keychain. On app launch, call configure() to restore any existing session:

Step 3: Sign In

After getting credentials from your backend, sign in with the SDK. The SDK supports two authentication modes:
The userId parameter is the Open Wearables User ID (UUID) — the id returned by the Create User endpoint. Do not pass your own external_user_id here.

API Key Authentication

For simpler setups (e.g. internal tools), you can use API key authentication directly:
API key authentication embeds the key in the app. Only use this for internal or trusted applications. For production apps, always use token-based authentication.

Automatic Token Refresh

When you provide a refreshToken, the SDK automatically handles 401 responses by refreshing the access token and retrying the request. No additional configuration is needed. You can also update tokens manually if needed:

Step 4: Request Permissions

Request access to specific health data types using the HealthDataType enum:
The HealthDataType enum provides type-safe access to all supported health data types. The string-based requestAuthorization(types: [String], completion:) overload is deprecated — use the enum variant instead.
On iOS, users can grant partial permissions. The SDK will sync whatever data the user allows. Apple’s privacy model means your app cannot determine which specific types were denied.

iOS Permission UI

When requesting permissions, iOS shows a system dialog listing all requested data types. Users can toggle each type individually.
Request only the data types you actually need. Requesting too many types can overwhelm users and reduce acceptance rates.

Step 5: Start Background Sync

Enable background sync to keep data flowing even when your app is in the background:

Controlling Sync History Depth

By default, the SDK syncs all available historical data on the first sync. Use the syncDaysBack parameter to limit how far back the sync goes:

Background Sync Behavior

Background sync frequency is controlled by iOS and may vary based on battery level, network conditions, and user behavior. The 15-minute interval is a minimum - actual syncs may be less frequent.

Stop Sync

Log Level

Control SDK log output using setLogLevel. By default, the SDK uses .debug, which outputs logs only in debug builds:
Set .always during development or when troubleshooting sync issues in production. Switch to .none if you want to suppress all SDK output.

Complete Integration Example

Here’s a complete service class showing the full integration:

Using the Service

Data Sync Endpoint

The SDK sends health data to:
Data is automatically normalized to the Open Wearables unified data model and can be accessed through the standard API endpoints.

Internal Architecture

The SDK uses a modular architecture with several internal components:

Next Steps

Troubleshooting

Common issues and solutions for native iOS.

Data Types

Available health metrics and data formats.