registerForRemoteNotifications gives neither a token nor an error for one bundle ID in production; development-signed build registers instantly

Question

Created 2w

Replies 5

Boosts 0

Participants 2

On a single device, a production-entitlement build of our app calls -[UIApplication registerForRemoteNotifications] and neither delegate callback is ever invoked. Not application:didRegisterForRemoteNotificationsWithDeviceToken:, and not application:didFailToRegisterForRemoteNotificationsWithError:. We wait 10 seconds and get nothing, on every launch, over more than 24 hours.

UNAuthorizationStatus is .authorized, verified programmatically at the moment of the call rather than just in Settings, and the installed binary carries aps-environment = production, read off the device. The identical source signed with aps-environment = development receives a token in under one second on that same handset.

We have isolated it to one cell of a four-way matrix. Production entitlement on this device: no token, no error, reproducing on both the App Store and TestFlight builds. Development entitlement on this device: token in under one second. Production entitlement on other devices: works, and other users register daily. Production APNs for other apps on this device: works, other App Store apps receive push normally.

Already ruled out: notification authorization; the entitlement; delegate wiring (UIApplicationDelegateAdaptor is attached, and that same delegate receives the token when the app is development-signed); delete and reinstall from both the App Store and TestFlight; Reset Network Settings; reboot; airplane-mode cycle; an alternate network.

Device context: iPhone 12 Pro (iPhone13,3) on iOS 26.6.1 (23G83). It is an AppleCare replacement unit, restored from a backup of the previous handset. Our working theory is stale per-app push registration state carried across in that restore, since reinstalling does not clear it, which suggests whatever is stuck does not live in the app container.

Filed as FB24525199 with a sysdiagnose captured while the APNs logging profile was installed.

Two questions. First, is there any way to force a device to discard and re-provision its per-app APNs registration state, short of erasing and setting up as new? Second, is the absence of both callbacks a known state? Every reference I can find treats didFailToRegisterForRemoteNotificationsWithError as the guaranteed path when registration cannot complete, so silence from both leaves an app with no signal to act on and no way to tell the user what is wrong.

Answer 1

DTS Engineer OP

Apple

2w

Thanks! Looks like you just filed it, I'll make sure to route it to the correct team.

You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label "Resolution." We're unable to share any updates on specific reports on the forums.

For more details on when you'll see updates to your report, please see What to expect after submission.

Albert  WWDR

Answer 2

joshmarsh OP

2w

Thank you for that!

Answer 3

joshmarsh OP

2w

Update!

I built a minimal test app (bare UIApplicationDelegate, single call to registerForRemoteNotifications(), no dependencies) and signed it ad hoc with aps-environment: production under the same team, on the same iPhone 12 Pro.

Minimal app, different bundle ID, production: token in 4 ms.
Minimal app, same bundle ID (MarshlandSoftware.Grid-Getter-App), production: token in 4 ms.
Real app, same bundle ID, same ad-hoc production profile, same device, same session: neither delegate method fires, confirmed twice with release logging raised to debug.

Entitlements on the failing and succeeding binaries are identical (application-identifier, aps-environment: production, team-identifier, get-task-allow: false). So this is not the device, the bundle ID, the entitlement, or the production environment — my earlier claim that production APNs was broken for this device was too broad, and I withdraw it.

What remains: the same binary registers normally on other users' devices, but on this one handset it calls registerForRemoteNotifications() and receives no callback at all. Still investigating on our side; posting the correction so nobody chases the wrong thing.

Answer 4

joshmarsh OP

2w

Resolved...and it was not APNs, and not the device. Posting the conclusion so nobody chases the wrong thing.

The bug is in our own dependency. posthog-ios (3.69.6) captures push subscriptions by swizzling application(_:didRegisterForRemoteNotificationsWithDeviceToken:), and that option defaults to on. On this iPhone 12 Pro the swizzle swallowed the callback entirely — neither the success nor the failure delegate method ever fired, so the app never received a token.

Bisected against a minimal app built with the same bundle id, team and production entitlement, which registered in 4 ms on the same handset. With PostHog's capturePushNotificationSubscriptions set to false and everything else in the SDK left on, our own app registers normally.

My original report was wrong in one important way: I claimed neither delegate method fired, but I inferred that from a missing log line. Our release log level is .warn and the success callback logs at .info, so its absence proved nothing. Once I forced the level up, the picture was unambiguous.

Withdrawing FB24525199. Apologies for the noise, and thanks to those who looked.

Answer 5

DTS Engineer OP

Apple

2w

@joshmarsh Thanks for providing this, 3rd party libraries do sizzle RegisterForRemoteNotifications and that could cause the token never received. I would suggest to add the comment in the FB for the team to know as well as use the Sample Push Notifications that is all native.

Thanks

Albert  WWDR