A HealthKit observer callback is a signal to reconcile, not a payload containing the changed samples. Respond with a bounded local workflow, retain recoverable progress and call the background delivery completion handler according to Apple’s contract. Keep remote upload outside the assumption that a callback guarantees uninterrupted execution.
Prerequisites include the actual native observer registration, required entitlement and permission setup, supported sample types and a persisted synchronization policy. A JavaScript permission list alone cannot establish that background delivery is registered or that the bridge preserves the native completion lifecycle.
A wake-up starts reconciliation
Apple says observer updates indicate that matching samples were added or deleted; another query is needed to retrieve the changes. Its background-delivery guidance requires completing the delivery after processing and testing on a physical device. Treat registration frequency as a delivery contract, not a promise that JavaScript runs at an exact interval.
Apple: executing observer queries and completing background delivery
An anchored change query may fit an incremental reader. A bounded full reconciliation may fit a small interval. Either approach needs stable source identities and deletion handling. Keep an observer event ID or local work marker separate from the data checkpoint: two wake-ups can point at overlapping work, and one wake-up can require several reads.
Define local completion independently of upload
| Phase | Persisted result | Meaning |
|---|---|---|
| Observer received | Pending reconciliation marker | Work is required |
| Changes read and applied | Records plus checkpoint | Local view reconciled |
| Upload queued | Outbox entry | Backend not yet current |
| Delivery completed | Native completion called | This delivery was handled |
The table is a proposed design, not an executed device trace. When networking is unavailable, a durable upload queue allows the local phase to finish without pretending that the coach portal already has the records. If the product requires a remote acknowledgment before some action, represent that as a separate pending state rather than holding a background callback indefinitely.
The exact order of local work and completion must fit the native API and execution budget. Persist enough information to resume before declaring the delivery handled. On errors, follow Apple’s documented handling and retain a recoverable marker; do not turn an exception into a successful empty import. Avoid an unbounded retry loop inside the callback.
Make process interruption a normal test case
Walk through termination before the query, after applying changes and before checkpoint commit. Repeating a reconciliation should produce the same logical records. When deletes arrive, remove the mapped contribution and invalidate the affected summary. A checkpoint saved without its changes can lose work; a checkpoint held back requires replay-safe application.
Coalesce concurrent observer events so two handlers do not race the same checkpoint. Scope work by account and sample type. When an account changes, old queued work must not upload under the new identity. A durable queue also needs ownership and retention rules; merely writing a JSON blob is not a complete synchronization design.
Capture physical-device evidence
The reviewed UltraFit360 source range is an authorization block. It names relevant data reads but does not establish an observer implementation. Use that source as context for integration scope, and require a separate native trace before describing background delivery as implemented. No observer device test was executed for this guide.
A useful acceptance record includes device and OS, build and bridge version, app state at the event, query outcome, checkpoint movement, completion-handler invocation and later upload result. Use a test account and synthetic records. Verify offline recovery, repeated delivery, protected-data unavailability and process relaunch. Report observed delivery times without converting a small test into a guaranteed cadence.
Keep observer registration and work execution separately inspectable. A registered observer can exist while a later reconciliation fails, and a foreground import can succeed without proving background registration. The release trace should identify which trigger initiated each job. This prevents a manual refresh during testing from accidentally being counted as successful background delivery, and gives the team a way to reproduce the failing phase without repeatedly changing permissions or removing the app.
Healthkit deleted samples sync
Bring the specific record types, device/OS targets and one failing or proposed data journey to scope a wearable integration review.
Does a HealthKit observer callback contain changed samples?
No. It signals that matching data changed. Reconcile with an appropriate query and complete background delivery according to Apple’s lifecycle.
Does background delivery prove the backend has new data?
No. Local reconciliation and remote upload are separate states and should be tracked separately.