RORK LABJP
GROWTH — Rork keeps growing with 743K monthly visits and an 85% growth rateMAX — Rork Max generates native Swift apps for iPhone, iPad, Watch, TV, Vision Pro, and iMessageMAX — It reaches AR/LiDAR scanning, Metal 3D games, Live Activities, HealthKit, and Core ML, beyond React Native's reachSTACK — Standard Rork builds iOS and Android together in React Native (Expo), so non-engineers can ship real appsPRICE — Plans start free, paid tiers from $25/month, and Rork Max at $200/monthMARKET — Gartner projects 75% of new apps will be low-code or no-code by the end of 2026GROWTH — Rork keeps growing with 743K monthly visits and an 85% growth rateMAX — Rork Max generates native Swift apps for iPhone, iPad, Watch, TV, Vision Pro, and iMessageMAX — It reaches AR/LiDAR scanning, Metal 3D games, Live Activities, HealthKit, and Core ML, beyond React Native's reachSTACK — Standard Rork builds iOS and Android together in React Native (Expo), so non-engineers can ship real appsPRICE — Plans start free, paid tiers from $25/month, and Rork Max at $200/monthMARKET — Gartner projects 75% of new apps will be low-code or no-code by the end of 2026
Articles/Dev Tools
Dev Tools/2026-07-04Advanced

Your Rork Max Health App Misses Overnight Steps — Designing Background Delivery When HKObserverQuery Dies Silently

In a native Swift health app generated by Rork Max, data recorded while the app is closed never arrives — and it's almost always because HKObserverQuery's background delivery stopped without a word. Here's how to isolate the layer that broke and an observation layer you can drop in as-is.

Rork Max213HealthKit4background deliveryHKObserverQuerySwift40iOS102

Premium Article

I built a tiny step-tracking app with Rork Max, and in the simulator it was flawless. Push health samples in by hand and they appear on screen instantly. But after running it on a real device for a few days, I noticed something odd: the moment I opened the app in the morning, the whole run of steps from the previous evening was missing, and only after a while did the numbers reconcile. No error, ever. Updates simply weren't arriving while the app was closed.

The cause was that HKObserverQuery's background delivery was registered in name only — it never actually became active. As an indie developer working with HealthKit, this "works in the foreground, dies quietly when closed" pattern is the first thing that trips you up. This walks through adding an observation layer to a Rork Max native app — one that keeps collecting health data while the app is asleep — with the smallest diff possible: how to isolate the silent failure, and an implementation you can use as-is.

HealthKit background updates are a three-stage stack

Most people assume one HKObserverQuery is enough, but to receive updates while the app is closed you have to satisfy three independent mechanisms at once. If you don't separate them mentally, one stays missing and you're stuck on "why won't it arrive."

Stage one is authorization: read access must be granted for the type you want (for steps, HKQuantityType(.stepCount)). Stage two is background-delivery registration — calling enableBackgroundDelivery(for:frequency:) per type to tell the system "wake me when this type changes." Stage three is the observer query itself, which receives the change signal and goes to fetch the actual data.

The nasty part: even when only read access is granted, the background-delivery registration API does not return an error. Registration looks successful, yet no notification ever comes. That asymmetry is where the silent failure breeds.

First, isolate which stage broke — from logs

Chasing this by guesswork burns hours. I always start by instrumenting each of the three stages and confirming on-device from logs how far execution reaches.

import HealthKit
import os
 
let healthLog = Logger(subsystem: "net.rorklab.sample", category: "health")
 
final class HealthObservation {
    let store = HKHealthStore()
    let stepType = HKQuantityType(.stepCount)
 
    func bootstrap() async {
        // Stage 1: authorization
        do {
            try await store.requestAuthorization(toShare: [], read: [stepType])
            healthLog.info("auth requested")
        } catch {
            healthLog.error("auth failed: \(error.localizedDescription)")
            return
        }
 
        // Stage 2: background delivery registration
        do {
            try await store.enableBackgroundDelivery(for: stepType, frequency: .hourly)
            healthLog.info("background delivery enabled")
        } catch {
            healthLog.error("bg delivery failed: \(error.localizedDescription)")
        }
 
        // Stage 3: observer query
        startObserver()
    }
}

You can pass .immediate for frequency, but demanding immediate delivery for a type that changes as often as steps just gets throttled by the system and thinned out anyway. For cumulative types like steps and distance I settled on .hourly. I consider it more robust in practice to reserve .immediate only for types that genuinely need responsiveness, like heart rate tied to a workout.

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
You can isolate from logs whether the failure is in authorization, background-delivery registration, or the observer's lifetime — the three independent layers that must all hold
You get a thin wrapper that pairs HKObserverQuery with HKAnchoredObjectQuery and always calls the completion handler, ready to drop into Rork Max's generated code
You'll know exactly which Info.plist keys, capabilities, and on-device background constraints to fill in by hand — the parts Rork Max cannot generate
Secure payment via Stripe · Cancel anytime

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

Dev Tools2026-07-04
Your Rork Max App Loses the Photos a User Picked After Relaunch — The Trap of Holding Onto URLs Under Limited Photo Access
In a native Swift app generated by Rork Max, photos picked via PHPickerViewController become unreadable after relaunch — because holding onto a URL or PHAsset no longer works in the age of limited access. Here's a design that copies the actual bytes into your own storage the instant they're picked.
Dev Tools2026-07-04
Start a Live Activity Without Launching Your Rork Max App — Designing Around a push-to-start Token That Never Arrives
In a native Swift app generated by Rork Max, you want to start a Live Activity from your server without the user ever opening the app. But the push-to-start token is never observed and it fails silently. Here's the cause and an observation layer that reliably captures the token.
Dev Tools2026-07-04
Direct Device-to-Device Sharing in Rork Max Apps — The Local Network Permission Trap That Makes MultipeerConnectivity Fail Silently
How to add serverless, nearby device-to-device sharing to a native Swift app generated by Rork Max. It works in the simulator but no peers ever appear on real devices — and the culprit is almost always a silent Local Network permission failure.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →