This guide walks through the end-user experience when your app integrates Sahha to collect health and wearable data. It covers the default connection flow, what users see during authorization, and how they can manage or revoke data sharing at any time.
Video walkthrough
The following video demonstrates the complete permissions flow from the user’s perspective on iOS, including the Apple Health authorization sheet and data sharing controls.
The default connection flow
When a user opens your app for the first time and the Sahha SDK is initialized, the following steps occur:
Step 1: SDK initialization
Your app initializes the Sahha SDK in the background. No user-facing prompt appears at this stage. The SDK connects to Sahha’s servers and prepares to collect data.
Step 2: Sensor permission request
The app requests permission to access device sensors. On iOS, this presents a standard system dialog asking the user to allow motion and fitness data access. On Android, this requests the relevant activity recognition permissions.
The user can approve or deny this request. If denied, Sahha can still collect limited data from non-sensor sources, but coverage will be reduced.
Step 3: Apple Health / Health Connect authorization
This is the primary consent step. The app requests access to specific health data categories through the native OS permission sheet:
On iOS (Apple Health):
- The user sees a standard Apple Health authorization sheet
- Each data type is listed individually (e.g., Steps, Heart Rate, Sleep Analysis, Workouts)
- The user can toggle each data type on or off independently
- The user must explicitly tap “Allow” to grant access
- No data is shared until the user actively approves
On Android (Health Connect):
- The user sees the Health Connect permissions screen
- Each data type is listed with read/write permissions shown separately
- The user can approve or deny each category individually
Step 4: Data collection begins
Once permissions are granted, Sahha begins collecting data passively in the background. No further user interaction is required. The SDK collects data according to the permissions the user approved and sends it to Sahha’s servers for processing.
What data sharing controls are presented
The user has full control over their data sharing at every stage:
- Granular opt-in: Users choose exactly which data types to share during the Apple Health / Health Connect authorization step. They are never forced to share all-or-nothing.
- No hidden data collection: Sahha only accesses the data types that were explicitly authorized by the user through the native OS permission sheet.
- Transparent data types: The permission sheet clearly lists every data category being requested, using Apple’s or Google’s standard UI and naming.
How users can manage, limit, or revoke data sharing
Users retain full control after the initial connection:
Revoking via device settings
iOS:
- Open Settings → Health → Data Access & Devices
- Find the app name
- Toggle off individual data types or remove access entirely
Android:
- Open Settings → Health Connect
- Find the app name under “App permissions”
- Revoke read or write access per data type or disconnect entirely
Revoking via your app
Your app can call Sahha’s deauthenticate method to programmatically disconnect the user and stop all data collection. This is useful for implementing an in-app “disconnect” or “delete my data” button.
Data deletion
Under GDPR and Sahha’s data handling policies, users can request full deletion of their data. Sahha supports complete data deletion via the API, ensuring no residual data remains after a user disconnects.
Privacy and compliance summary
| Requirement | Sahha’s approach |
|---|---|
| User consent | Native OS permission sheets (Apple Health / Health Connect) with granular per-type controls |
| Data minimization | Only collects data types explicitly authorized by the user |
| Revocation | Users can revoke at any time via device settings or programmatically via the SDK |
| Data deletion | Full deletion support via API, compliant with GDPR right to erasure |
| Encryption | AES-256 encryption in transit and at rest |
| PII handling | No PII stored beyond birthdate and biological sex (if provided) |
| Compliance | HIPAA compliant (BAA available), GDPR compliant, SOC 2 Type II audited |
Further reading
- Security and Compliance — Full details on Sahha’s security posture
- SDK Documentation — Technical integration guides
- Platform Overview — How data flows through Sahha