For an application supporting iOS 16 and later, including iOS 18 and newer releases, I would like to clarify the supported guarantees for deciding whether persisted monotonic time evidence belongs to the current boot. I have read the DTS reply in “Time verification in iOS 18+” and the linked recommendation to use CLOCK_MONOTONIC with an exclusively created POSIX named semaphore: https://developer.apple.com/forums/thread/774658?answerId=825483022#825483022 https://developer.apple.com/forums/thread/110044?answerId=754364022#754364022 That recommendation describes semaphore cleanup on restart as a reasonable assumption. My question is specifically about the documented guarantees and safe failure conditions of that approach, rather than another request for a replacement for kern.bootsessionuuid. The required distinction is between process or application-engine restarts during the same boot and an actual device reboot. A continuity mechanism should remain valid across the former and distinguish, or safely invalidate, observations retained across the latter. It must not depend on an assumed-stable wall clock or on comparing uptime magnitudes that could overlap after a reboot. For an App Group-namespaced semaphore on supported iOS versions: Is cleanup at every device reboot, and persistence across ordinary process termination or suspension within a boot, a documented guarantee that an application may rely on? What sandbox, resource-limit, lifecycle or name-reuse conditions can invalidate that inference? Is there a supported way to avoid treating a recreated or unrelated same-name semaphore as proof that older persisted observations belong to this boot? If those guarantees cannot be established, is there another supported boot-continuity mechanism? Please identify its OS availability and applicable privacy or required-reason API constraints. No raw boot identifier or raw uptime needs to be sent off-device. If supported cross-process continuity cannot be established, is a continuously alive native process's sleep-inclusive monotonic clock a documented comparison domain until that process ends? In that narrower design, all previous-process observations would be invalidated, accepting the loss of same-boot recovery. A process UUID or application-engine identity would not be treated as an operating-system boot identity. I am seeking documented guarantees, limitations or supported alternatives, not an undocumented sysctl or an inference from macOS behavior. This question concerns clock-domain continuity; it does not assume that continuity alone proves when a location observation was originally acquired.

For an application supporting iOS 16 and later, is there a supported public API that exposes a monotonic timestamp for the original determination of a CLLocation, rather than the time it is delivered to CLLocationManagerDelegate? The requirement is to reject observations whose original acquisition age exceeds 10,000,000,000 ns at the final native transport-dispatch check. Exactly 10 seconds is allowed; 10 seconds plus 1 ns is rejected before conversion to milliseconds. This is an arithmetic boundary requirement, not an assumption that location measurements have nanosecond physical accuracy. CLLocation.timestamp is a Date for when the location was determined. Sampling a continuous monotonic clock in didUpdateLocations instead measures callback receipt. Cached observations, batched updates and delayed background delivery can separate those events. Does a public API provide either: A monotonic acquisition/determination timestamp associated with that same CLLocation; or A documented finite uncertainty bound and supported method for relating its Date timestamp to a sleep-inclusive monotonic clock at dispatch? How do the documented guarantees handle wall-clock adjustments between determination and delivery, device sleep, suspension, queued updates and process restarts? If a newer API supplies stronger evidence, what is its minimum supported iOS version? If neither mechanism is available, is there a supported request or delivery mode that establishes a documented lower bound on the original determination time and can reliably reject older cached observations? A recent callback or request by itself would not establish that relationship. I would appreciate documentation describing the guarantees, limitations or supported alternatives. I have not established that such a mechanism is impossible; this is a capability clarification, not a claim of a reproduced operating-system defect.