Reading Steps and Sleep into Your Rork Max Native App — HealthKit for Calm, Number-Light Wellness Apps

Step 2: Request read and write separately

HealthKit splits "read" and "write" into different grants. Steps are read-only; meditation time is write-only. Request only the direction each type actually needs.

import HealthKit
 
final class HealthStore {
    let store = HKHealthStore()
 
    // Keep read and write types separate
    private let readTypes: Set<HKObjectType> = [
        HKQuantityType(.stepCount),
        HKQuantityType(.heartRate),
        HKCategoryType(.sleepAnalysis)
    ]
    private let writeTypes: Set<HKSampleType> = [
        HKCategoryType(.mindfulSession)
    ]
 
    func requestAuthorization() async throws {
        guard HKHealthStore.isHealthDataAvailable() else {
            throw HealthError.unavailable   // always check on unsupported devices like iPad
        }
        try await store.requestAuthorization(toShare: writeTypes, read: readTypes)
    }
}
 
enum HealthError: Error { case unavailable, denied, noData }

Skip the isHealthDataAvailable() check and the app crashes on HealthKit-unsupported devices (some iPad configurations). I learned this from a production crash log. It belongs there from day one.

Step 3: Read steps and produce "today's total"

With access granted, aggregate the steps. HealthKit returns a set of samples, so the cleanest way to sum them is HKStatisticsQuery.

extension HealthStore {
    func todayStepCount() async throws -> Int {
        let type = HKQuantityType(.stepCount)
        let start = Calendar.current.startOfDay(for: Date())
        let predicate = HKQuery.predicateForSamples(withStart: start, end: Date())
 
        return try await withCheckedThrowingContinuation { continuation in
            let query = HKStatisticsQuery(
                quantityType: type,
                quantitySamplePredicate: predicate,
                options: .cumulativeSum
            ) { _, stats, error in
                if let error { continuation.resume(throwing: error); return }
                let steps = stats?.sumQuantity()?.doubleValue(for: .count()) ?? 0
                continuation.resume(returning: Int(steps))
            }
            self.store.execute(query)
        }
    }
}

Returning ?? 0 matters in practice. Even with permission granted, if the user hasn't walked yet that day, the result comes back with zero samples. Mistaking that for a "permission error" leads to pointless retries and alarming error banners. Treat "no data" and "no permission" as distinct states.

Step 4: Keep ingesting steps while the app is closed

For a calm app, the experience hinges on the latest number already being there the moment the user opens it. That means receiving step updates even when the app is not foregrounded. HealthKit pairs HKObserverQuery with Background Delivery.

extension HealthStore {
    func startStepObserver(onUpdate: @escaping () -> Void) {
        let type = HKQuantityType(.stepCount)
 
        let observer = HKObserverQuery(sampleType: type, predicate: nil) { _, completion, error in
            if error == nil { onUpdate() }
            completion()   // ← omit this and iOS stops sending updates
        }
        store.execute(observer)
 
        store.enableBackgroundDelivery(for: type, frequency: .hourly) { success, error in
            if let error { print("background delivery failed: \(error)") }
        }
    }
}

Forgetting completion() is the trap that cost me the most time. Without it, iOS decides the app "can't keep up" and silently halts further background deliveries. The maddening symptom — working in testing, then gradually going quiet in production — traces back to exactly this. Keeping the frequency around .hourly is realistic; .immediate wrecks the battery trade-off.

Step 5: Write relaxation time back

Beyond reading, writing meditation and breathing sessions back as "mindful minutes" gathers the user's records in one place and raises satisfaction.

extension HealthStore {
    func saveMindfulSession(start: Date, end: Date) async throws {
        let type = HKCategoryType(.mindfulSession)
        let sample = HKCategorySample(
            type: type,
            value: HKCategoryValue.notApplicable.rawValue,
            start: start,
            end: end
        )
        try await store.save(sample)
    }
}

Note that write permission, even when denied, does not raise an error — it behaves as if the save succeeded. For privacy, Apple makes write authorization undetectable from the app. So rather than reading the value back to confirm, the correct behavior is to advance the UI on the assumption the write succeeded.

What to suspect when production data is "zero"

The most common post-launch message is "I allowed it but no number shows." I work through it in this order. First, in Settings → Privacy → Health, is read access for the app actually on? Users toggling off only part of the dialog is more common than you'd expect. Second, does real data for that day exist at all? A late-night report often just means the person hasn't walked yet. Third, is it a device where isHealthDataAvailable() returns false? Surfacing these distinctions in your UI messaging makes support dramatically lighter.

On the revenue side, health integration sits well as a broadly open free feature, supported by ordinary AdMob delivery, with detailed retrospectives and long-term graphs behind a monthly membership. Holding health data itself hostage behind a paywall is something I'd avoid, both for honesty and for review.

How to choose the background-delivery frequency

Frequency design is a trade-off between freshness and battery drain. In my wellness apps I keep step updates at .hourly. The reason is simple: users open the app maybe two or three times a day, so minute-level freshness adds almost nothing to the experience. Comparing .immediate and .hourly for a week each on a test device, the perceived battery cost was a non-trivial difference, and battery complaints in reviews are a churn driver that feeds straight into revenue.

As a rule of thumb, here is what I recommend. For a "look-back" app where users actively come to check a number, .hourly is plenty. For a "reminder" app that wants to notify goal completion instantly, raise the frequency but narrow the target to steps alone to contain battery impact. Because HealthKit wakes the app more often as you observe more types, my settled production stance is to always reason about type count and frequency together.

Your next move

Ship just one thing first — step reading, within the scope of Steps 1–3 above. Every additional HealthKit type raises your review burden, so shipping a minimal build, watching how users respond, then expanding to sleep and heart rate is the order that stays manageable for an indie developer. My own first release carried steps only, and I added sleep later as reactions came in. I hope it helps anyone trying to build a quieter experience on top of health data.