RORK LABJP
MAX — Rork Max is built on Claude Code and Claude Opus 4.6, generating native Swift apps directly instead of React NativeAPPLE — Rork Max targets the whole Apple ecosystem: iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and iMessageWORKFLOW — In practice, users settle into letting the AI scaffold while they rewrite the state management and data layer themselvesSEED — Rork raised a $15M seed led by Left Lane Capital in April, with Peak XV, True Ventures, and a16z Speedrun joiningPAPERLINE — Rork acquired app builder Paperline and says it will stay acquisitive to bring in engineering talentREVIEW — Three-month revisit reviews are growing, clarifying where the tool shines and where it doesn'tMAX — Rork Max is built on Claude Code and Claude Opus 4.6, generating native Swift apps directly instead of React NativeAPPLE — Rork Max targets the whole Apple ecosystem: iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and iMessageWORKFLOW — In practice, users settle into letting the AI scaffold while they rewrite the state management and data layer themselvesSEED — Rork raised a $15M seed led by Left Lane Capital in April, with Peak XV, True Ventures, and a16z Speedrun joiningPAPERLINE — Rork acquired app builder Paperline and says it will stay acquisitive to bring in engineering talentREVIEW — Three-month revisit reviews are growing, clarifying where the tool shines and where it doesn't
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 Max223HealthKit5background deliveryHKObserverQuerySwift45iOS109

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-13
Losing HealthKit Data on Incremental Sync — Designing HKQueryAnchor Persistence
When step or sleep data double-counts or goes missing on incremental HealthKit sync, the root cause is usually HKQueryAnchor persistence. Here is a working Swift design that handles newAnchor and deletedObjects correctly and stays consistent across reinstalls and background updates.
Dev Tools2026-07-11
Implementing App Clips with Rork Max — delivering the core of your app the moment someone scans a code
Building on the native Swift that Rork Max produces, this note walks through the 15 MB App Clip budget, receiving the launch URL, and handing state off to the full app.
Dev Tools2026-07-08
Working Around Rork Max's 20-Geofence Wall with Dynamic Re-registration
In a native Swift app generated by Rork Max, geofences you registered quietly stop firing past a certain count — and it's almost always iOS's silent limit of 20 monitored regions per app. Here's a dynamic re-registration design that keeps only the nearest 20 live, plus a Swift implementation you can drop in.
📚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 →