Post

Replies

Boosts

Views

Activity

Reply to registerForRemoteNotifications gives neither a token nor an error for one bundle ID in production; development-signed build registers instantly
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.
2w
Reply to registerForRemoteNotifications gives neither a token nor an error for one bundle ID in production; development-signed build registers instantly
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.
2w
Reply to registerForRemoteNotifications gives neither a token nor an error for one bundle ID in production; development-signed build registers instantly
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.
Replies
Boosts
Views
Activity
2w
Reply to registerForRemoteNotifications gives neither a token nor an error for one bundle ID in production; development-signed build registers instantly
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.
Replies
Boosts
Views
Activity
2w
Reply to registerForRemoteNotifications gives neither a token nor an error for one bundle ID in production; development-signed build registers instantly
Thank you for that!
Replies
Boosts
Views
Activity
2w