How does the Apple Push Notification service deliver a push: tokens, priority, collapse, expiry, and what can go wrong?

A remote notification travels provider (your server) → APNs → device → app. At launch the app calls registerForRemoteNotifications(); the system obtains a device token from APNs and returns it in application(_:didRegisterForRemoteNotificationsWithDeviceToken:); the app uploads it to your server along with the user and environment (sandbox or production tokens are different). The server authenticates to APNs with a token-based key (a .p8 signing key, the modern way: one key per team, no yearly renewal) or with certificates, and sends an HTTP/2 request to /3/device/<token> with headers: apns-topic (the bundle id, with suffixes for push types such as .voip), apns-push-type (alert, background, voip, liveactivity…), apns-priority (10 delivers immediately and may wake the screen; 5 is power-aware and may be delayed, required for silent background pushes), apns-expiration (how long APNs stores a push for an offline device; 0 means try once and discard) and apns-collapse-id (a newer push with the same id replaces the older undelivered one, so a device that was offline gets only the latest score update, not fifty).

The guarantees are weak by design. APNs is best effort: it holds only a limited number of undelivered pushes for an offline device (so older ones can be discarded), replaces an undelivered push that has the same collapse id, may drop pushes under load, and does not tell you whether the user saw it (a 200 means APNs accepted it). Silent pushes (content-available with background type) are throttled by the system (a few per hour), not delivered to force-quit apps (the user swiping the app away in the switcher stops background delivery until they launch it again, though visible alerts still arrive), and must not be relied on for correctness: use them as a hint to sync, with the app also syncing at launch. Common failures: a token from the wrong environment (BadDeviceToken), an expired or revoked token (410 Unregistered: delete it server-side, and re-register on each launch because tokens can change), a payload over the 4 KB limit, the wrong topic or key, a Focus mode or Low Power Mode hiding or delaying it, and notification permission being off. For rich content use a mutable-content push with a notification service extension (which has about 30 seconds to modify it). Design: send identifiers, not secrets, in payloads (the content passes through Apple), make handling idempotent, put the real data behind an authenticated fetch, and use collapse ids and appropriate priorities to limit noise. The background-delivery rules and silent-push limits are also covered in the platform topic.