Thanks, Kevin—this answers our remaining questions and gives us a practical path forward. We’ll start with a minimal test comparing the sensor timestamps with systemUptime, then use that baseline to check our app’s behavior. We’ll keep the claim to coarse association with the capture operation, rather than precision the system wasn’t designed to provide. Really appreciate the detailed explanations and implementation advice.

"Separately, does CMDeviceMotion (gyroscope/accelerometer) timestamping follow the same software-stamping path, or is IMU data timestamped closer to the sensor?"

Thank you, Kevin—this helps considerably. We’re aiming for coarse association with an application operation, not sub-millisecond pressure timing. Your point that the altimeter does not perform its own timestamping raises one remaining question: what event does CMAltitudeData.timestamp represent—receipt of a sensor reading by the system, creation of the Core Motion event, or an estimate of when pressure was measured? Can a newly delivered event contain an older or filtered pressure measurement whose age is not represented by that timestamp? For implementation, is comparing that timestamp directly with operation boundaries sampled using ProcessInfo.systemUptime, while monitoring for unexpected divergence, a reasonable approach for this coarse association? We understand that this would not establish the physical measurement instant or a guaranteed error bound.