Platform support
The facade keeps common workflows uniform while preserving platform-specific privacy and capability rules.
Baseline
| Platform | Minimum OS | Native API |
|---|---|---|
| Android | Android 8.0 / API 26 | Health Connect |
| iOS | iOS 15 | HealthKit |
Operation matrix
| Operation | Android | iOS | Notes |
|---|---|---|---|
| Read | ✓ | ✓ | Type and OS availability vary. |
| Write | ✓ | ✓ | Requires per-type authorization. |
| Update | ✓ | — | Health Connect-specific capability. |
| Delete | ✓ | ✓ | Native ownership rules apply. |
| Aggregate | ✓ | ✓ | Metrics vary by data type and platform. |
| Incremental sync | ✓ | ✓ | Unified through platform cursor mechanisms. |
| Background read | Capability-based | Capability-based | Requires permission and OS scheduling. |
Important differences
iOS read authorization
HealthKit does not disclose whether a user denied read permission. Read permission checks return unknown; applications should execute the query and accept an empty result as valid.
Android declarations
Every requested Health Connect type must have a matching <uses-permission> entry. Missing declarations produce a configuration error before the operation can succeed.
Feature discovery
Newer records and operations can depend on Health Connect SDK extensions or OS releases. Use getFeatureStatus() for optional capabilities and keep fallbacks in product flows.
Record availability
Not every conceptual record has a perfect equivalent on both platforms. Consult the generated API documentation and the platform annotations on each data type before designing a cross-platform feature.