Unable to receive HealthKit updates when app is force-quit — need clarification on background delivery limits

Question

Created 3w

Replies 1

Boosts 0

Participants 2

Hello,

I’m developing a HealthKit-based fitness app in React Native that observes step count changes and uploads the latest totals to a remote server.

I’m currently using HKObserverQuery with background delivery enabled (enableBackgroundDelivery(for:frequency:.immediate)), and the behavior works correctly while the app is running in the background or foreground.

Whenever new step data is written to HealthKit, the app wakes up, reads the latest data, and sends it to my HTTPS endpoint using URLSession.shared.dataTask inside the observer callback.

However, I’ve noticed the following issue:

1. If the user swipes up (force-quits) the app from the app switcher, the observer queries stop firing entirely.

2. In this state, even though HealthKit continues collecting step data from the device or Apple Watch, my app no longer receives those background deliveries until the user opens the app again.

What I would like to achieve is:

When the app is terminated (swiped up), and there are new step count updates in HealthKit, my app should still be able to receive those updates or be relaunched to handle them — similar to how some health companion apps continue syncing data and sending notifications even after being force-quit.

So I have a few questions:

Is this limitation expected — i.e., does iOS intentionally block HKObserverQuery background deliveries after a user force-quits the app?

2.	Are there any special entitlements, background modes, or Apple-approved mechanisms that allow a health or medical app to continue receiving HealthKit changes even after a force-quit?

3.	If not, what is the recommended architecture for apps that need to process HealthKit data continuously and send it to a backend server? For example, should such apps rely on server-side push notifications or CloudKit sync once the user reopens the app?

My current goal is to ensure step count changes are uploaded reliably even if the app is killed, but I want to stay within the system’s supported behaviors and privacy constraints.

Any clarification or guidance from Apple engineers or others who have implemented continuous HealthKit sync (like companion or medical apps) would be greatly appreciated.

Thank you.

Boost

Answer 1

Engineer OP

Apple

3w

As explained in iOS Background Execution Limits ==>

When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. So: If the app is running, iOS terminates it. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually.

This gesture is a clear statement of user intent; there’s no documented way for your app to override the user’s choice.

So, the best approach to this is first train your users so they understand that force quit will stop data collection. And if they still do it, then it is their choice for you to respect.

So, how you solve this depends on your use case and the user experience you are trying to achieve.

You can send push notifications if your server suspects that this has happened (no data updated for a while, for example) to encourage the users to tap on it, which will relaunch the app and reset the state that the app has been force quit.

Alternatively, you can implement a Notification Service Extension which will execute when you send the above mentioned notification (regardless the user taps it or not), and try reading the data you need from the Health database and send it to your server.

A caveat is, the extension runs in a limited memory, time, and access sandbox, and this may or may not necessarily be enough for you to accomplish what you want to do. You can test this and implement it in your app if it looks feasible.

0