Thank you for your interest in contributing to HealthKMP! We welcome contributions, bug fixes, and feature additions to make Kotlin Multiplatform health data integration seamless across Android, iOS, and watchOS.
Please take a moment to review the following guidelines before submitting a Pull Request.
To keep the codebase predictable and maintainable, all data type declarations, extension functions, mapping logic, and sample screens must be strictly kept in Alphabetical (A-Z) order:
HealthDataTypeenum/object declarations in HealthDataType.kt- Extension functions in
commonMain/extensions.ktand platform-specificextensions.kt when (type)branching blocks inHealthConnectManager.kt,HealthKitManager.kt, andAggregation.kt- Sample app screen files in
sample/composeApp/src/commonMain/.../sample/dataType/
- Align method and parameter names with Health Connect and established health platform standards (e.g.,
aggregateGroupByDurationmatches Health Connect'sAggregateGroupByDurationRequest). - Public extension functions must adhere to the standard prefix pattern:
read<DataType>()(e.g.,readSteps(),readBloodPressure())write<DataType>()(e.g.,writeWeight())aggregate<DataType>()(e.g.,aggregateHeartRate())aggregate<DataType>GroupByDuration()(e.g.,aggregateStepsGroupByDuration())
- Code in
commonMainmust be pure Kotlin Multiplatform code. - No platform-specific imports (
java.*,android.*,Foundation,UIKit) incommonMain. Use KMP-native libraries likekotlinx-datetimeandkotlinx-coroutines. - Public asynchronous functions in
HealthManagermust returnResult<T>for robust error handling.
- Record data models (e.g.,
StepsRecord,WeightRecord) should include input range validation (init { require(...) }). - Use named arguments when instantiating data models (especially in unit tests) to prevent parameter swaps (e.g., systolic vs. diastolic) and improve code readability.
Every PR introducing a new health data type, aggregation metric, or feature must update the sample app:
- Update
sample/composeAppto include UI screens and controls for testing the new data type or feature. - Ensure empty list states (
records.isEmpty()) are handled gracefully without causing division by zero or UI crashes.
Every feature or bug fix must include corresponding tests:
commonTest: Unit tests for shared logic and data models.androidHostTest: Validation for Health Connect record mapping (runs on JVM).appleTest: Validation for HealthKit record mapping (shared by iOS and watchOS).
# 1. Update and check binary API compatibility dump
./gradlew :health:apiDump
# 2. Run API check to verify compatibility
./gradlew :health:apiCheck
# 3. Run all tests across all platforms
./gradlew :health:allTests
# 4. Verify Swift framework linking for Apple targets
./gradlew :health:linkDebugFrameworkIosArm64 :health:linkDebugFrameworkWatchosArm64The project uses the Binary Compatibility Validator to ensure public API stability. When making changes to public interfaces or data classes:
- Run
./gradlew :health:apiDumpto update the.api/.klib.apifiles. - Commit the updated API dump files along with your code changes.
Before opening a Pull Request, ensure:
- Code follows Alphabetical (A-Z) ordering everywhere.
- Method and extension function naming matches Health Connect / platform conventions.
-
sample/composeAppis updated with UI for testing your changes. - Tests added in
commonTest,androidHostTest, andappleTest. -
./gradlew :health:apiDumpwas run and.apifiles are committed. -
./gradlew :health:apiCheck :health:allTestspasses locally.