Provisioning profiles created for my App ID are not including the Push Notifications capability, even though Push Notifications is enabled in the App ID configuration in Apple Developer Portal. I have enabled Push Notifications for my App ID (com.abc.app) in the Apple Developer Portal. The capability shows as enabled and saved. However, when provisioning profiles are generated (either manually or through third-party tools like Expo Application Services), they do not include: The Push Notifications capability The aps-environment entitlement This results in build failures with the following errors: Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't support the Push Notifications capability. Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't include the aps-environment entitlement. Steps Taken ✅ Enabled Push Notifications in App ID configuration (com.mirova.app) ✅ Saved the App ID configuration multiple times ✅ Waited for Apple's systems to sync (waited 5-10 minutes) ✅ Removed and re-added Push Notifications capability (unchecked, saved, re-checked, saved) ✅ Created Push Notification key in Apple Developer Portal ✅ Verified Push Notifications is checked and saved in App ID ❌ Provisioning profiles still created without Push Notifications capability Expected Behavior When Push Notifications is enabled for an App ID, any provisioning profiles created for that App ID should automatically include: Push Notifications capability aps-environment entitlement (set to production or development) Actual Behavior Provisioning profiles are created without Push Notifications capability, even though: Push Notifications is enabled in App ID App ID configuration is saved Sufficient time has passed for sync Additional Information Push Notification Key: Created and valid (Key ID: 3YKQ7XLG9L and 747G8W2J68) Distribution Certificate: Valid and active Provisioning Profile Type: App Store distribution Third-party Tool: Using Expo Application Services (EAS) for builds, but issue persists with manually created profiles as well Questions Is there a delay or sync issue between enabling Push Notifications in App ID and it being available for provisioning profiles? Are there any additional steps required to ensure Push Notifications is included in provisioning profiles? Is there a known issue with Push Notifications capability not being included in provisioning profiles? Should I create the provisioning profile in a specific way to ensure Push Notifications is included? Environment Platform: iOS Build Type: App Store distribution Xcode Version: (via EAS cloud build) Thank you for your assistance. I've been unable to resolve this issue and would appreciate any guidance. iOS Deployment Target: Latest

There's plenty of articles out there about programatically grouping push notifications. However I have tried setting the thread-id in the push payload when sending a push, or setting the threadIdentifier for a received push in a notification service extension to be the same for several pushes. But if within the iPhone Settings / Notifications the user selects to display pushes as List and turns off Notification Grouping, then each notification resulting from the push appears on its own separately. Is there something other than thread-id/threadidentifier that is used to programmatically group them? If not then whats the point of these as grouping and display is actually under the control of user.

I am trying to issue the "start" APNs push notification to start a live activity for my iOS app. The notification appears to send correctly, there is no error message, but the live activity never appears for any of my users (users are in TestFlight). In addition to issuing the APNs commands from my server, I have also tried using the CloudKit Push Notification Console to manually generate a "start" notification. It submits correctly but the live activity never starts. I have also checked the Console app to watch the device logs and see if iOS is rejecting/throttling the live activity but I don't see any activity related to the start message at all. Here are some details: App bundle ID: `com.penzu.moodmoji` APNs topic: `com.penzu.moodmoji.push-type.liveactivity` APNs push type: `liveactivity` Recent apns-id: `7b633309-b7fd-4163-b620-776efa04f315` APNs payload: { "aps": { "timestamp": 1742651625, "event": "start", "content-state": { "totalDays": 7, "currentDay": 2, "progress": 0.29, "status": "ACTIVE", "reportReady": false }, "attributes-type": "GoalActivityAttributes", "attributes": { "totalDays": 7, "currentDay": 2, "progress": 0.29, "status": "ACTIVE", "reportReady": false }, "alert": { "title": "It's day 2!", "body": "Don't forget to record every time you feel anxious today." } } } I can confirm that LiveActivities started by the iOS app with ActivityKit work correctly, and the app does appear to be receiving pushToStartTokenUpdates: struct GoalActivityAttributes: ActivityAttributes, Sendable { struct ContentState: Codable & Hashable, Sendable { let totalDays: Int let currentDay: Int let progress: Double let status: String let reportReady: Bool } let goal: SimpleGoal } for await nextStartToken in Activity<GoalActivityAttributes>.pushToStartTokenUpdates { // send nextStartToken to server... } The app I'm testing with is in TestFlight, using the production APNs environment.

Hello, I have a question regarding the replacement of the APNs authentication key (.p8) in a Firebase setup for push notifications. Currently, my app uses an APNs authentication key from the original Apple Developer account. However, we are in the process of transferring app ownership to a new Apple Developer account, which will require generating a new APNs authentication key and updating it in Firebase. My concerns are: Impact on Existing Device Tokens: If we replace the existing .p8 key with a new one generated from the new developer account, will the existing APNs device tokens remain valid, or will they need to be reissued? Push Notification Delivery: Will Firebase still be able to send push notifications to devices that were registered with the previous APNs authentication key after the key is replaced? Steps for a Smooth Transition: Are there any best practices or additional steps we need to follow to ensure uninterrupted delivery of push notifications during and after the key replacement? Any insights or guidance from the Apple Developer team or community would be greatly appreciated.

My app will be woken when Activity.pushToStartTokenUpdates delivered the new token. But I want to know how can I get the activity.pushTokenUpdates when my server start an live activity via push notification, because without the activity.pushTokenUpdates, my server can't deliver update information after start the live activity. For now, I check the activities when my app switch foreground/background. But how can I be notified when my app is in foreground and server start an live activity by push notification. I've tried "content-available": 1 in LA's payload aps, but I also can't be notified in the didReceiveRemoteNotification in appDelegate.

Only iOS devices stop receiving notifications after a few days of the app being installed. To resolve this, you need to reinstall the app again. I'm using Firebase to send messages.

Hi Everyone, I noticed that applicationIconBadgeNumber has been deprecated in iOS17. While there's a new method to set the badge number using setBadgeCount(_:withCompletionHandler:), I couldn't find a way to retrieve the current value. Previously we used to call UIApplication.shared.applicationIconBadgeNumber, to get the current value, which is deprecated now. Does anyone know how to get the current badge count? Thanks!

We have just been granted access to the com.apple.developer.usernotifications.filtering entitlement, and are following the documented steps for handled E2EE VOIP notifications listed here: https://developer.apple.com/documentation/callkit/sending-end-to-end-encrypted-voip-calls 1 - A user initiates a VoIP call on their app. Their app then sends an encrypted VoIP call request to your server. We do exactly this, Alice calls Bob from her app, sending a notification to our servers. 2 - Your server sends the encrypted data to the receiver’s device using a regular remote notification. Be sure to set the apns-push-type header field to alert. We do exactly this, our server send on a notification to APNS with the apns-push-type header set to alert, destined for Bob. 3 - On the receiver’s device, the notification service extension processes the incoming notification and decrypts it. If it’s an incoming VoIP call, the extension calls reportNewIncomingVoIPPushPayload(_:completion:) to initiate the call. It then silences the push notification (see com.apple.developer.usernotifications.filtering). I try to do exactly this. The notification is received by the NSE on Bob's device, which decrypts it and then notices it is a VOIP call from Alice. It prepares a dictionaryPayload with the decrypted data and then calls reportNewIncomingVoIPPushPayload(_:) async throws. This throws an NSXPCConnectionInterrupted error, which when logged shows as below: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.callkit.notificationserviceextension.voip" UserInfo={NSDebugDescription=connection to service named com.apple.callkit.notificationserviceextension.voip} The only difference I can see to the documentation is that I am working in an asynchronous context so am using the asynchronous version of the method, but I don't imagine this should cause an issue? I then supress the notification as documented and this works correctly. Does anyone have any ideas why I am getting this error when calling reportNewIncomingVoIPPushPayload(_:) async throws?

Hi All, im working on a project to send a push notification in CarPlay. Current accepted by apple entitlements is driving. Are custom actions / buttons allowed/supported in CarPlay notifications?

token:009739d008a19dbe7e2273a1e4e8b5f73c4e2d7e220e7308f41e316f4c2fcf56 最近app无法收到服务端通过apns推送的通知，提交是成功的，但是app的所有用户都无法收到通知

Hi Apple Dev Team, We have a React Native application that includes call functionality using PushKit and VoIP notifications. We are using APNS to send the VoIP notifications, and everything has been working smoothly on iOS versions up to 18.3.1. However, after updating to iOS 18.4, we are no longer receiving incoming VoIP push notifications on the device. There have been no code changes related to our PushKit or notification logic — the exact same build continues to work correctly on devices running iOS 18.3.1 and earlier. We're trying to understand if anything has changed in iOS 18.4 that affects VoIP push delivery or registration behavior. Would appreciate any guidance, and happy to share code snippets or configuration if needed. Thanks in advance!

Hi, Regarding the announcement about the Apple Push Notification Service (APNs) Server Certificate Update, I wanted to clarify whether it will impact my app’s push notification setup. I use Firebase Cloud Messaging (FCM) to send push notifications to iOS devices, and in my Firebase project settings, I have configured an APNs Authentication Key under the Apple app configuration tab (Firebase Console > Project Settings > Cloud Messaging > iOS app configuration). The authentication key I am using was generated from Apple Developer > Certificates, Identifiers & Profiles > Keys. Since I am using this authentication method instead of APNs certificates, are there any changes I need to be aware of due to the APNs server certificate update, and do I need to update anything in my current configuration to ensure push notifications continue to work? Thanks in advance!

I have multiple app ids that are registered with Push Notification, however they do not hsow up in the Push Notification Console for testing.

I got notification filtering permission from appStoreConnect, i.e. com.apple.developer.usernotifications.filtering, but not able to suppress notification even after setted contentHandler(UNNotificationContent()) and contentHandler(UNMutableNotificationContent()). Added entitlements in both extension and main app, also in signing profile these Entitlements are visible, what other changes should I do?

Having some discussion about when we should clear out a token from our servers. Docs say: Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. You can retry with a delay, if you get the error code TooManyRequests. The way I see it is that with the exception of PayloadTooLarge, all other errors means you should remove the token from your server. Either because: The token is no longer good The token is good, but this is just not the right: environment (sandbox vs production) topic (the token is from a different bundle id or developer team) target (app vs live activity appex) Do I have it right? Extra context: when using the "JSON Web Token Validator" tool, a colleague reported that a 410 -Expired token (from couple days back) was still valid today. This raises questions about when tokens should actually be deleted and how these error codes should be interpreted. Also is it possible for the docs to get updated for us to explicitly know if a token should get removed and not leave it for interpretation?

Hello, We are facing issue that sometimes a voip notification gets delivered after it is expired. The issue can be simply demonstrated we set the device to flight mode, and after 20s we disable flight mode. We still receive the voip notification. We are setting the expiration header as following apns-expiry=0, so from my understanding it should not be delivered if the device was not able to receive the notification in the fist attempt. I have read following thread https://developer.apple.com/forums/thread/778512, from which I understand this is a long standing issue. Hence my question is, is there any way how we can notify the call kit that the call is actually no longer valid, and do not display the call to the user at all? Currently we are forced to always display CallKit call when the notification comes, and some of our users are confused that they see a missed call which they did not have any chance to pick up. Please let me know if you need any more information. Best Regards, Adam Chlupacek

Push-notification token is properly requested and displayed from the iOS simulator / xcode, but not from the release in the AppStore... Both popups for permission (push-notifications and critical alert) appear and can be confirmed, but no callback takes place...

I'm attempting to leverage notifications in an app that is in Swift 6 language mode. I have the following code: func startLocationUpdates() { //if self.manager.authorizationStatus == .notDetermined { // self.manager.requestWhenInUseAuthorization() //} self.logger.info("Starting location updates") Task { do { let updates = CLLocationUpdate.liveUpdates() for try await update in updates { if !self.updatesStarted { break } // End location updates by breaking out of the loop. self.lastUpdate = update if let loc = update.location { self.lastLocation = loc self.isStationary = update.stationary self.count += 1 self.logger.info("Location \(self.count): \(self.lastLocation)") } if lastUpdate!.insufficientlyInUse { let notification = UNNotificationRequest(identifier: "com.example.mynotification", content: notificationContent, trigger: nil) try await UNUserNotificationCenter.current().add(notification) } } } catch { self.logger.error("Could not start location updates") } return } } As an aside, the above is directly taken from the following sample: https://developer.apple.com/documentation/CoreLocation/adopting-live-updates-in-core-location. With Swift 6 language mode enable, this generates a compiler error for the statement: try await UNUserNotificationCenter.current().add(notification) Sending main actor-isolated 'notification' to nonisolated instance method 'add' risks causing data races between nonisolated and main actor-isolated uses How can I fix this?

How do i add the red bubble badge notification on the app for unread in app messages

When sending a single push notification to iOS 18 devices users receive the same notification multiple times. This issue appears specific to iOS 18 and was not observed in previous iOS versions Our server logs confirm each notification is sent only once. Notification payloads include proper apns-id values for identification and no network issues detected on our side