I am using a Key to connect my notification server with APNS in order to send out notifications to users. I have recently added notifications to a second app of mine, using the same notification server to fire off notifications for both apps. However, any notifications going to the second app return the error InvalidProviderToken, where as I get no such issues when send notifications to the first app. Everything, including the payloads, are exactly the same between the two apps, the only difference is that the device IDs are attached to different apps. Does anyone know why/how this would happen and how I can resolve it?

Push message on the lock-screen disappears in one specific instance. In general the situation is as follows: the application, upon starting up, sets the badge counter (i.e. notificationCenter.setBadgeCount(3)) the application is being sent to background the screen is locked (it doesn't matter if it's turned on or not) send a push message to the application and set the badge (in aps) to "0" What happens: the screen lights up (unless it's lit up already), the push is being displayed for a very short time and gets hidden. Happens on iOS 18.1, 18.1.1, 18.2. If not setting badge in the aps keys it works correctly. I've created a feedback report https://feedbackassistant.apple.com/feedback/16095572. I am able to reproduce the issue on a sample app 100% of the time :/

If an iOS application has a notification service extension which gets sent a push, but the user has not been prompted for notification authorization via requestAuthorization() then what is the expected behavior? Will the push get delivered to the NSE but the resulting notification not displayed? Or will the push not get delivered at all to the NSE?

We experienced an issue with delayed App Store Server notifications for an Auto-Renewable Subscription purchase in our app. On September 27, 2024, at 22:28:28 GMT+0900, a user successfully purchased a Premium membership subscription (transaction ID: 190002223966278, webOrderLineItemId: 190001007274949). However, our server did not receive the corresponding App Store notification for this transaction after purchase. The App Store Server Notification was only received 66 minutes later, at 23:35:16 (transaction ID: 190002224000004, webOrderLineItemId: 190001007274949). The delayed notification contained a different transaction ID than the initial purchase. We would like to inquire about the cause of this delay and request assistance in understanding why the notification took 66 minutes to be delivered to our server, instead of arriving immediately after the transaction was completed. Additionally, we would appreciate your guidance on how to prevent or mitigate such delays in the future, ensuring a seamless experience for our users. Are there any best practices or recommended approaches we should implement to handle potential notification delays more effectively? We have provided detailed information about the received notification and the related transactions in the Feedback Assistant (FB15330451). Thank you for your assistance in resolving this matter. Key Details Purchase time: 2024-09-27T22:28:28 GMT+0900 (1727443708000) Notification received: 2024-09-27T23:35:16 GMT+0900 (1727447716463) Delay: 66 minutes and 48 seconds Initial Purchase Transaction ID: 190002223966278 Initial Purchase Web Order Line Item ID: 190001007274949 Transaction ID in Delayed Notification: 190002224000004 Web Order Line Item ID in Delayed Notification: 190001007274949 Additional info Bundle ID: com.reppley.ReppleyApp SKU: com.reppley.ReppleyApp Feedback Assistant Number: FB15330451

Hello, since updating (last night) to developer beta 18.2, I no longer have email count numbers / badges showing. I don’t know if others are experiencing this, but thought I should report it.

For devices running iOS 18 and iPadOS 18 or later, you can add input-push-token: 1 to your payload to start a Live Activity and receive a new push token. After you receive a new push token, you can use it to send updates to a Live Activity. I read from https://developer.apple.com/documentation/ActivityKit/starting-and-updating-live-activities-with-activitykit-push-notifications#Start-new-Live-Activities-with-ActivityKit-push-notifications that I can start a live activity from CUSTOM SERVER by the start token I get from MyApp.Does that paragraph means my CUSTOM SERVER can receive a new token from aps? If not, how can update the live activity started by Push-Notification when MyApp doesn't alive? And what "input-push-token: 1 " can do, when I put it in the payloads?

https://forums.developer.apple.com/forums/thread/685317 Having read the above discussion, I can add there’s one problematic exception on watchOS to the rule that .didBecomeActiveNotification is fired when the Control Center or any other overlay (such as a long-look notification) is dismissed. It’s when it’s dismissed not by the user, but just allowed to dsimiss itself after a period (as determined by Settings > Wake Duration). This is a problem for any Watch workout app because when one of these overlays is covering the app, it’s considered by the system to be backgounded for purposes of applying the 15% avg CPU load over 60 seconds criteria for being terminated for using too much CPU in the background, so I have discovered. In the case of these overlays covering an app, the app never gets a .didEnterBackgroundNotification call to know that it should attempt to reduce its activity, when the user presses the Side Button to show the Control Center, which is by design, as I understand it. The app does get a .willResignActiveNotification when the Control Center covers it, but there is no corresponding .didBecomeActiveNotification when the system dismisses the Control Center after 2 minutes or so. So if the app reduces its actvity in an attempt to reduce CPU load when covered by the Control Center overlay, it has no way to know it has become active again, in the special case of the Control Center timing out and being dismissed by the system. What could be done to reduce the likelihood of the system terminating the app in this situation, and maintain the app's functionality and usability?

I am trying to build a chat app. I am using FCM to deliver messages to my app accompanied by some custom data like the new message_data, deleted message_id and so on; each message will need to run the app in the background to do some background processing and local database syncing. This continuous background processing is clearly not acceptable as APNs imposes a per-device limit on background push notifications . I am asking how can I push messages and actions payload without being throttled ?

Dear all, I am seeking your assistance to finalize my registration in the Apple Developer Program. I have attempted to register multiple times using valid payment cards, but I received an email stating that my request would be processed within two business days, and that $99 would be deducted. However, two days have passed without any progress. I am unsure if the issue is related to using my friends' cards, despite their validity. In my last attempt, I provided a photo of my friend's ID card and his passport as proof of his consent for the deduction. Could the discrepancy between the cardholder's information and my registration details be the cause of the problem? Thank you.

When I turn the Ringtone and Alerts volume all the way up, I expect standard notifications to play at the loudest level the device allows. In theory, this should match the volume of a critical alert with its sound.volume set to 1.0 in payload. However, I’ve noticed that non-critical notifications still play quieter than critical alerts under these conditions. Critical alerts with volume: 1.0 sound noticeably louder than standard notifications, even though the Ringtone and Alerts slider is already set to maximum. And I couldn't find a documentation for this behavior anywhere. Is this expected behavior on iOS? And is there any way to make non-critical notifications play at the same maximum loudness as critical alerts? Thanks in advance for any clarification.

I've added a Notification Service Extension as a target to my React Native iOS app following Apple's official documentation. After completing all the setup steps as outlined in the documentation, the notification titles remain unchanged - notifications are arriving without any modifications, suggesting the extension isn't functioning properly.Testing Details: Sending notifications via Apple Push Notification Console Tested on iPhone 16 Pro Max (physical device) Tested on iPhone 15 Pro simulator Both show the same issue - no title modifications The extension appears to not be executing at all. Has anyone encountered similar issues with Notification Service Extensions in React Native projects, or can suggest troubleshooting steps to verify the extension is properly configured and running?

An Application Group with Identifier 'group.com.aaa.aaa.onesignal' is not available. Please enter a different string. How can I Fix this error? I need to add it in this format.

I want to add Live Activities to my e-commerce app to show the estimated delivery ETA when an order is out for delivery, with the Live Activity initiated from the server. Issue 1: How can I consistently obtain a pushToStart token when a user logs in to my e-commerce app? Currently, I’m considering starting and ending a dummy Live Activity to retrieve the token. Is there a better way to trigger pushToStartTokenUpdates and send the token to my server? Issue 2: How do I properly invalidate the pushToStart token when a user logs out, ensuring the next user doesn’t inherit the same token? Ideally, I don't want the user to wait until the token is automatically invalidated before logging out.

I am currently implementing VoIP push notifications in my iOS app using PushKit. On iOS 18, I am able to receive VoIP notifications successfully when the app is in the foreground. However, when the app is in the background or in a terminated (kill) state, the notifications do not arrive. In earlier iOS versions, my existing implementation worked as expected across all app states. This issue seems to have started after testing on iOS 18, which appears to have introduced stricter permission or background execution requirements. Questions: Has iOS 18 introduced new permission requirements or entitlements for VoIP push notifications? Do I need to explicitly request a new type of user permission for VoIP notifications? Are there additional background modes, Info.plist keys, or PushKit changes required for VoIP to work in background and terminated states on iOS 18? Additional Information: . Foreground: Works fine, pushRegistry(_:didReceiveIncomingPushWith:for:completion:) is triggered. . Background/Terminated: No call to the above delegate method. . Using correct voip push type in the payload. . PushKit is configured in AppDelegate. . Background modes for "Voice over IP" and "Background Processing" are enabled. . Using a real device with iOS 18 for testing (not simulator). Any guidance or updated documentation references for handling VoIP pushes in iOS 18 would be greatly appreciated.

We currently are checking to see if we need to make modifications to account for the new Certification Authority (CA) for APNs that will be changing soon. Since we currently use the newer token-based connection to APNs and not the certificate-based connection, would we be unaffected by this change?

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.

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?

I have read from previous posts in the forum and in StackOverflow that the limitation of 64 notification is still present with the current iOS18 version right? Inside testflight I was not able to reproduce this limit and was wondering if it only applies to the AppStore. Is it only a limit of scheduled notifications or is there also a limit of delivered notifications ? I find the Apple documentation lacking detail in this regard. If the latter is the case, I will not bother building a notification manager to deal with frequent notification scheduling. thank you in advance S.

Hi, My customer has acquired the assets of another company. We therefore need to transfer this company's app to my customer's account. This app primarily functions using WebRTC video, which relies on APN PUSH notifications. I have reviewed the information about transferring an app from one developer account to another, particularly here: https://developer.apple.com/help/app-store-connect/transfer-an-app/overview-of-app-transfer. I understand that we need to generate a new SSL certificate that will be integrated into the app once it has been transferred. Since users will not all update the app immediately, we will have two server certificates running in parallel for some time. Is it allowed to send two notifications to the same iPhone, knowing that one of the two will systematically fail? If not, what is the best practice for successfully migrating VOIP notifications? Thank you in advance, F. BABIN

We are in the process of transferring our app to a new Apple Developer Organization account. Our app uses the Apple Push Notification service (APNs) with a .p8 authentication key configured on our server to send push notifications. We would like to confirm: Once the app transfer is completed, will push notifications continue to work temporarily using the existing .p8 key on our server, until we generate and configure a new .p8 key under the new organization's account? Understanding this behavior is critical for us to ensure a smooth transition and avoid any disruption in push notification delivery for our users. Thank you for your guidance and support.