Hello, I’m developing an iPhone safety application for people working alone outdoors. The app uses CMMotionManager accelerometer updates to detect prolonged inactivity while the phone is worn on the body, including when the screen is locked. In a physical iPhone test, we recorded 7,232 samples over approximately 12 minutes, including 6,925 samples tagged as background. Delivery intervals were stable. However, we cannot establish a documented relationship between CMAccelerometerData.timestamp and a host monotonic clock that would let us reliably determine each sample’s acquisition-to-consumption age. My questions are: Is CMAccelerometerData.timestamp guaranteed to be directly comparable to ProcessInfo.systemUptime or mach_absolute_time? How does this relationship behave across device sleep/wake and app suspension/resumption? Can Core Motion deliver previously buffered accelerometer samples after the app resumes? Is there a supported way to calculate or conservatively bound the actual age of an individual accelerometer sample? Our current implementation deliberately treats samples as unverified until their freshness can be established. We do not interpret stable callback intervals as proof of fresh measurements. Any guidance from Apple engineers or developers familiar with Core Motion timestamp semantics would be greatly appreciated. Thank you!

How can Core Motion accelerometer sample age be reliably verified on iOS?

Hello,

I’m developing an iPhone safety application for people working alone outdoors.

The app uses CMMotionManager accelerometer updates to detect prolonged inactivity while the phone is worn on the body, including when the screen is locked.

In a physical iPhone test, we recorded 7,232 samples over approximately 12 minutes, including 6,925 samples tagged as background. Delivery intervals were stable.

However, we cannot establish a documented relationship between CMAccelerometerData.timestamp and a host monotonic clock that would let us reliably determine each sample’s acquisition-to-consumption age.

My questions are:

Is CMAccelerometerData.timestamp guaranteed to be directly comparable to ProcessInfo.systemUptime or mach_absolute_time?
How does this relationship behave across device sleep/wake and app suspension/resumption?
Can Core Motion deliver previously buffered accelerometer samples after the app resumes?
Is there a supported way to calculate or conservatively bound the actual age of an individual accelerometer sample?

Our current implementation deliberately treats samples as unverified until their freshness can be established. We do not interpret stable callback intervals as proof of fresh measurements.

Any guidance from Apple engineers or developers familiar with Core Motion timestamp semantics would be greatly appreciated.

Thank you!