Is background accelerometer monitoring possible for seismic detection?

Update: I’ve filed this as an enhancement request — FB24275258 — asking for a purpose-scoped entitlement for background accelerometer access limited to seismic detection, with on-device thresholds and only trigger events leaving the device. Still interested in whether there’s a supported approach today that I’ve missed.

Thanks for your enhancement request.

You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see What to expect after submission.

Albert  WWDR

As one small correction...

CMSensorRecorder is watchOS-only.

Where did you see that? Strictly speaking, it does require a degree of hardware support, but that won't really matter unless you're planning to support the iPhone 6 and iOS 12. We never released a formal spec for this, but I believe it works on A10 hardware and above.

I’m not looking for a workaround. Is there any supported way to do this on iOS, for instance, restricted to when the device is stationary and charging? Or is this outside what the platform currently allows?

There isn't currently a background solution for this, and, realistically, I'm not sure how we'd really build one that would really work for you. The core problem here is that you want to be "realtime", but the primary strategy our background APIs use to save power... is to suspend the app whenever possible. There are two background categories which keep an app awake indefinitely, which is why most real-time motion analysis apps either:

• Use "audio" and provide some kind of real-time feedback/guidance/etc.

Or

• Use "location" and track the user location in real-time.

...as those are the only two categories[1] which can easily/reliably keep an app awake indefinitely. A real-time motion background category would basically be identical to either of those and probably worse due to the frequent wakeups ACTUAL[2] real-time analysis requires. Theoretically we could have a “motion” background category, but I suspect its behavior and power characteristics would be VERY similar to location, which makes the effort harder to justify.

[1] Strictly speaking, CoreBluetooth "can" but only during active interaction with an accessory.

[2] Most "user motion" analysis doesn't ACTUALLY need to be done in real time and is in fact often better handled by polling at regular intervals and processing sensor data in real-time, which is why CMSensorRecorder is actually the "default" API I suggest for most apps. See this thread for more details.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin, thanks for the correction and your reply.

I've read the other thread you mentioned, and honestly, it might work well for another type of project. The problem is that the polling interval becomes the alert latency and more fundamentally, the polling loop itself needs the process to be awake, which is where that thread ended up too: there's no wake path for it. The key is anticipating the S-wave by a few seconds, so if the data arrives even a minute late, it's useless for an alert system.

I understand the power argument, but I think it's worth mentioning something that might change the math: the mode I'm asking for only runs while the device is stationary and charging. At that point the frequent-wakeup cost lands on a phone sitting on a nightstand, plugged in. That profile doesn't really look like the location category anymore.

And this isn't theoretical, Android has been running this exact pattern for years, at two levels actually. Google's own Earthquake Alerts System works OS-level on charging, stationary phones: thresholding on device, only trigger events go up. And independent of that, third parties like Earthquake Network have done the same thing through a plain foreground service, sensor access with a persistent notification, restricted to charging. Years in production, and the charging constraint keeps the cost where it belongs. So the question of whether a mode like this is viable already has an empirical answer. For what it's worth, that same thread you linked ended with FB24300192 asking for a user-authorized, condition-triggered CoreMotion wake, my FB24275258 is essentially the narrow life-safety version of the same gap.

Last Monday made the gap very visible here. The M7.4 earthquake in Colombia on August 10: Android users got a warning up to ~30 seconds before the shaking, iPhones stayed silent (no government EEW infrastructure here, and Apple's Enhanced Safety Alerts only cover a few regions). It was all over the local press, literally headlines asking "why did Android warn me and my iPhone didn't". The hardware in those iPhones was sitting right there, charging on nightstands.

I'm not expecting any of this to exist today, and I get that the entitlement route is a long shot. Honestly if Apple solved it at the OS level like Google did, that would be an even better outcome than my FB. Mostly I want the case on record: narrow scope, power-neutral by construction, and a very recent real-world event showing what it's worth. Thanks again for taking the time.

I understand the power argument, but I think it's worth mentioning something that might change the math: the mode I'm asking for only runs while the device is stationary and charging. At that point, the frequent-wakeup cost lands on a phone sitting on a nightstand, plugged in.

Sure, I completely understand. The problem from an API design perspective is that either:

1. If you create a "broad" API, then it’s useful to lots of different developers, but it's also easy to abuse and difficult to restrict in a meaningful way.

2. If you create a "narrow" API, its usefulness is so narrow and limited that it's not actually being used for very much, which makes it hard to justify the work necessary to create and maintain the API.

To be clear, that doesn't mean the problem isn't important or worth solving, just that it's hard to justify creating an API that apps can use to solve it.

Honestly, if Apple solved it at the OS level like Google did, that would be an even better outcome than my FB.

If you haven't already filed it, you should absolutely file a bug asking for us to support this. As part of that, I'd also include links to:

It was all over the local press, literally headlines asking "why did Android warn me and my iPhone didn't".

...these sorts of articles.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware