Healthkit
Implement and review Apple HealthKit in Swift iOS and iPadOS apps without common authorization, availability, and background-sync mistakes.
Overview
healthkit is an agent skill for the Build phase that guides correct HealthKit availability, authorization, capability, and background-sync patterns on iOS and iPadOS.
Install
npx skills add https://github.com/dpearson2699/swift-ios-skills --skill healthkitWhat is this skill?
- Corrects iPadOS 17+ availability vs “HealthKit never works on iPad” myths
- Requires HKHealthStore.isHealthDataAvailable() before other HealthKit APIs
- Clarifies authorizationStatus(for:) reflects write/share, not read grant state
- Explains denied reads can return only app-owned samples (empty or partial data)
- Covers HealthKit capability plus NSHealthShareUsageDescription / NSHealthUpdateUsageDescription
Adoption & trust: 1.7k installs on skills.sh; 713 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are planning HealthKit reads and background sync but team assumptions about iPad support, authorizationStatus, and empty results on denial will break privacy behavior in production.
Who is it for?
Indie iOS developers adding step counts, workouts, or clinical-style samples with HKObserverQuery and background delivery.
Skip if: Teams building Android Health Connect only, server-side FHIR pipelines without a native HealthKit client, or apps that do not declare HealthKit capability.
When should I use this skill?
Reviewing or implementing HealthKit on iOS/iPadOS, authorization flows, background step sync, or correcting common HealthKit misconceptions.
What do I get? / Deliverables
You get corrected, platform-accurate HealthKit setup and review guidance aligned with Apple’s privacy model before you ship health features.
- Corrected HealthKit architecture notes
- Review feedback on availability and authorization
- Background sync timing recommendations
Recommended Skills
Journey fit
HealthKit is wired during product construction when the app needs health data reads, writes, and background observers. Integrations subphase is where third-party platform APIs like HealthKit, capabilities, and Info.plist usage strings belong.
How it compares
Use as a HealthKit correctness reviewer instead of copying Stack Overflow snippets that confuse read vs write authorization.
Common Questions / FAQ
Who is healthkit for?
Solo and indie builders using Claude Code or Cursor to implement or review Swift HealthKit features on iPhone and iPad.
When should I use healthkit?
During Build integrations when designing HKHealthStore setup, Info.plist usage strings, authorization flows, and background observer queries—or in Ship review when auditing a teammate’s HealthKit plan.
Is healthkit safe to install?
Review the Security Audits panel on this Prism page for pass/fail and risk signals before adding it to your agent; the skill is procedural guidance and does not grant network or shell access by itself.
SKILL.md
READMESKILL.md - Healthkit
{ "skill_name": "healthkit", "evals": [ { "id": 0, "prompt": "Review this HealthKit setup plan for an iOS 26/iPadOS app: the team says HealthKit never works on iPad, creates HKHealthStore before any availability check, treats authorizationStatus as proof that read permission was denied, and assumes denied reads always return empty arrays. Give concise corrected guidance.", "expected_output": "A correction-focused review that explains current platform availability, availability checks, write-vs-read authorization privacy, and partial app-owned results after read denial.", "files": [], "assertions": [ "States that HealthKit data is available on iPadOS 17 or later, not categorically unsupported on iPad.", "Requires HKHealthStore.isHealthDataAvailable() before using other HealthKit APIs.", "Explains that authorizationStatus(for:) reports write/share authorization, not whether read access was granted.", "Explains that denied read access can return only samples the app saved, so results may be empty or partial rather than a reliable denial signal.", "Mentions required HealthKit capability and NSHealthShareUsageDescription or NSHealthUpdateUsageDescription as appropriate." ] }, { "id": 1, "prompt": "Review this background step-count sync plan: enableBackgroundDelivery(.immediate) is called after the first dashboard screen appears, the HKObserverQuery is created only when the screen is visible, the completion handler is skipped on errors, and QA plans to validate the behavior only in Simulator. What should change?", "expected_output": "A review that fixes HealthKit background delivery setup, launch-time observer registration, completion handling, device testing, entitlement, and frequency expectations.", "files": [], "assertions": [ "Requires the HealthKit Background Delivery capability or com.apple.developer.healthkit.background-delivery entitlement.", "Says observer queries should be set up as the app launches, not only when a screen appears.", "Pairs enableBackgroundDelivery with an HKObserverQuery for the same sample type.", "Requires calling the observer completion handler even when processing fails.", "States that Simulator is not a valid background-delivery test target.", "Explains that requested frequency is a maximum and some types such as iOS step count may be capped hourly." ] }, { "id": 2, "prompt": "A team is building an iOS 26 workout recorder with HKWorkoutSession and HKLiveWorkoutBuilder. They also want the same code path to support iOS 17 devices, assume iPhone has live heart-rate samples like Apple Watch, and mirror Apple Watch workouts to iPhone whenever possible. Review the plan and identify HealthKit pitfalls.", "expected_output": "A workout-session review that distinguishes HKWorkoutSession and HKLiveWorkoutBuilder availability, handles live heart-rate collection on iPhone/iPad, and outlines correct mirroring setup.", "files": [], "assertions": [ "Distinguishes HKWorkoutSession availability from HKLiveWorkoutBuilder availability.", "States that HKLiveWorkoutBuilder requires iOS/iPadOS 26 or watchOS 5 and should be availability-gated for older iOS/iPadOS targets.", "States that iPhone and iPad need a paired external heart-rate sensor for live heart-rate collection.", "Mentions that Apple Watch can collect high-frequency heart-rate samples during workouts.", "For mirroring, starts mirroring from the watchOS session and assigns workoutSessionMirroringStartHandler early on the iOS app.", "Mentions lock-screen or locked-device workout data access considerations when showing live iPhone metrics." ] } ] } # HealthKit Extended Patterns Overflow reference for the `healthkit` skill. Contains advanced patterns that exceed the main skill file's scope.