Supported approach for real-time iPhone fall detection while an occupational lone-worker safety app is backgrounded?

Question

Created 1w

Replies 2

Boosts 0

Participants 3

Hi,

I'm developing SafeChain, an occupational lone-working safety application for iOS and Android.
One of our objectives is to detect a potential fall using the iPhone's accelerometer and notify an assigned responder if the worker doesn't acknowledge a warning.

The requirement is for this to work while the iPhone is locked or the app is backgrounded, without requiring an Apple Watch.

We've tested several approaches on a physical iPhone:

CMMotionManager: Works reliably in the foreground, but we recorded a 254-second interruption during a five-minute locked-screen test.

CMSensorRecorder: Successfully recovered 20,635 accelerometer samples from a seven-minute locked-screen recording, with a maximum sampling gap of 0.024 seconds.

BGAppRefreshTask: Scheduling requests were accepted, but we could not confirm timely background execution.

Our challenge isn't obtaining the accelerometer data. It's ensuring the application can analyse that data and initiate an emergency escalation promptly, even while iOS would ordinarily suspend the app.

SafeChain also provides lone-worker check-ins, manual SOS, responder escalation and contact-loss monitoring.
My questions are:

Is there currently an Apple-supported approach for continuous or event-triggered motion analysis on an iPhone while an occupational safety application is backgrounded?

Would a genuine lone-worker location-monitoring feature provide a legitimate basis for background location execution alongside Core Motion processing, assuming location tracking is itself an intended user-facing feature?

Is there an entitlement or alternative API specifically available for occupational safety applications requiring timely emergency detection?

If none exists, is it correct that dependable, real-time, iPhone-only fall detection is not currently supported by iOS?

We want to comply fully with Apple's guidelines and avoid implementing a background-execution workaround that may prove unreliable or fail App Review.

Any guidance from Apple engineers would be greatly appreciated.

Thank you,

Answer 1 · 1w

Pokpong OP

1w

From what you describe, the hard part is getting execution time, not collecting samples. CMSensorRecorder can give you data to analyze later, but it does not wake your app at the moment a fall happens. Core Motion callbacks and BGAppRefreshTask also should not be treated as a guaranteed real-time trigger while the app is suspended.

Background location is appropriate only if ongoing location sharing is a real, user-visible feature. I would not use it just to keep the process alive for motion analysis; location updates still do not provide a general guarantee that your code will run immediately.

For a safety workflow, I would make check-ins and a manual SOS the dependable paths, with a server-side missed-check-in escalation, and describe automatic fall detection as best-effort unless you can pair it with hardware that supports reliable detection. I would not promise iPhone-only, locked-screen real-time fall detection based on these APIs.

Answer 2 · 1w

7_strikes OP

1w

Background location will give you the execution time, and even if we assume that location sharing for a lone-worker is a justifiable use (and perhaps more so with some creative UX design), there are still some remaining bumps.

App Review Guidelines say: Use Location Services in your app only when it is directly relevant to the features and services provided by the app. Location-based APIs shouldn’t be used to provide emergency services

It's that second part that needs interpreting, preferably by someone who understands contracts/liabilities/legalspeak. But that said, there are a number of such lone-worker apps (including one I worked on) on the App Store, so that does not seem to be a blocker by App Review. Although they handle each app on a case-by-case basis, so YMMV.

The other problem is the power drain introduced by keeping the app running in the background, and a phone without power does not get to execute any code. So, brute forcing full time background execution without some smarter handling will not end well.

And a gotcha you should be aware of: if not careful, you will end up running both the location and motion updates on the same thread. Then the motion updates and the processing of them to determine a fall will saturate the thread, and starve the processing of the location updates arriving on the same thread. When the update queue fills up, the system will assume the app is not processing the updates anymore and will stop sending them. Once the location updates stop, your app gets suspended and that means no more execution time. The new CLLocationUpdate/CLBackgroundActivitySession are easier to use and handle in a separate thread than the old CoreLocation APIs.

S.Beck - 7strikes.dev