We're looking for clarification on how APNs enforces provider authentication token update limits across independent HTTP/2 connections. We operate a production APNs sender using ES256 JWT-based authentication. The sender: Signs a provider JWT using an APNs authentication key. Caches and reuses that JWT for approximately 50 minutes. Opens a new HTTP/2 connection to api.push.apple.com for each notification, then closes it after receiving the response. We want to perform a single-notification delivery test from a separate, short-lived process using the same Production APNs environment. Our concern is avoiding any disruption to the existing production sender. Apple's token-based connection documentation states that using a new authentication token too frequently can cause errors "on the same connection" and that "You can use the same token from multiple provider servers." The APNs response documentation also describes HTTP 429 TooManyProviderTokenUpdates. Questions Throttle scope: Is TooManyProviderTokenUpdates enforced strictly per HTTP/2 connection, or can it apply across connections sharing the same signing key, Apple Developer team, topic, or Production environment? Independent JWT signing: If our test process signs a fresh provider JWT using the same APNs key and sends one notification over a new HTTP/2 connection, could that cause throttling for our production sender, which continues using its previously cached JWT on separate connections? Separate signing keys: Would using a different APNs authentication key under the same developer team isolate token-update throttling, or could limits still be shared at the team or topic level? Recovery behavior: If APNs returns TooManyProviderTokenUpdates, how long does the restriction last? Can existing valid tokens on other connections continue working? Could continuing to send requests with an unchanged cached JWT prolong the restriction? Recommended approach: For a one-time delivery test alongside a production sender, is it preferable to reuse the existing cached JWT across processes rather than independently sign a new one? We have not executed the test because we want to understand the potential impact on production push delivery first. Any guidance from Apple engineers on the enforcement scope, recovery behavior, or recommended testing procedure would be appreciated. Thank you!

I'm looking for a documented, supported way for an iOS app to tell, on-device and without network access, that the device has restarted or been restored from a backup since a given point. The goal is to fail closed after either event. It is not to identify the device or user, and the value would never leave the device. I'm aware of the existing forum guidance (for example thread 110044 and thread 809339), which describes best-effort techniques. I'm asking whether a guaranteed mechanism exists. Specifically, does iOS provide a supported public API, or a documented combination of APIs, that offers all of the following: Unique per boot. A value guaranteed never to repeat across boots of the same device. This would cover every kind of restart: graceful shutdown, forced or watchdog reset, kernel panic, and power loss or battery depletion. Not resettable or rolled back. A value the app itself cannot reset, that deleting and reinstalling the app doesn't reset, and that restoring a backup can neither reset nor roll back to an earlier value. Changes on every same-device restore. A signal guaranteed to change observably whenever a backup is restored to the same physical device, from iCloud Backup or an encrypted Finder backup, with or without Erase All Content and Settings first. It must not be stored in, derived from, or rolled back by anything a backup restores. If no such API exists, it would help to know that too. And if some of these properties hold only as current implementation behavior rather than a documented guarantee, I'd appreciate knowing which. Thanks!