Hello, We are trying to implement Actionable Notifications on iOS via Remote Notifications. According to Apple’s official documentation (Declaring Your Actionable Notification Types), it is recommended to register notification categories at launch time. However, in our use case, the number of buttons and their actions in the Actionable Notification are determined at the time of the Remote Notification request. This means that we cannot predefine the categories at app launch but need to dynamically configure them based on the payload of the Remote Notification. Our Approach We are considering setting aps.mutable-content = 1 and using Notification Service Extension to modify the categoryIdentifier dynamically. Below is the JSON payload we plan to use for Remote Notifications: { "aps": { "alert": { "title": "New Message Received!", "body": "Check out the details." }, "category": "DYNAMIC_CATEGORY", "mutable-content": 1 }, "categoryData": { "id": "DYNAMIC_CATEGORY", "actions": [ { "id": "REPLY_ACTION", "title": "Reply", "options": ["foreground"] }, { "id": "DELETE_ACTION", "title": "Delete", "options": ["destructive"] } ] } } Questions: Can we dynamically configure Actionable Notifications based on the Remote Notification payload? If we set categoryIdentifier in Notification Service Extension’s didReceive(_:withContentHandler:), will users still see the correct action buttons even if the app is terminated? What is the recommended approach to dynamically configure Actionable Notifications at the time of receiving the Remote Notification, rather than at app launch?

Hi, We are building a system that integrates with APNs using the Token-Based Authentication method. While testing, we encountered the 429 TooManyProviderTokenUpdates error and would like clarification on the exact conditions that trigger this response. Our Testing Scenario: Private Key: We keep the same Private Key constant across requests. TEAM_ID and KEY_ID: For testing purposes, we change the TEAM_ID and KEY_ID for every JWT we generate. Requests: Each generated JWT is used to call the /3/device/{token} API endpoint. Observed Behavior: When we test with different TEAM_ID and KEY_ID combinations, we initially receive 403 InvalidProviderToken, which is expected because the TEAM_ID and KEY_ID combinations are invalid. However, if we change the TEAM_ID and KEY_ID and make multiple calls (e.g., more than two within 20 minutes), we start receiving 429 TooManyProviderTokenUpdates. If we switch to a different IP address (via VPN) after receiving the 429 error, we revert to receiving 403 InvalidProviderToken. Our Use Case: We are building a system where multiple server clusters handle multiple apps (some under the same Apple Developer account, others under different accounts). Each server generates JWTs for requests to the APNs /3/device/{token} API. Our Questions: What specific conditions cause the 429 TooManyProviderTokenUpdates error? Does APNs monitor token updates at the level of TEAM_ID and KEY_ID, or does it consider additional factors such as the originating IP address or shared infrastructure? How does APNs handle frequent changes in TEAM_ID and KEY_ID within a single server or cluster? Is there any documentation or guidance on managing JWTs effectively in a distributed system with multiple apps and servers? Does APNs limit JWT updates based on IP address or API endpoint usage across multiple apps sharing the same Apple Developer account? We would greatly appreciate any clarification on these points and guidance on best practices for managing JWTs in a multi-cluster environment. Thank you!

Hello, I am encountering an intermittent TopicDisallowed error while using APNs and would like to ask for your assistance. Environment: Authentication: We are using certificate-based authentication with APNs, where the PEM file is stored on the server to authenticate our requests. API: We are using the HTTP/2 API and calling the /3/device/<device_token> endpoint while passing the apns-topic in the request header. Issue: After renewing our APNs certificate, the new certificate mistakenly included an incorrect app bundle ID, resulting in a TopicDisallowed error. We then issued a new certificate with the correct bundle ID and replaced it on our server before resuming remote push requests. However, even after replacing the certificate, we are still intermittently receiving the TopicDisallowed error, while other requests successfully return a 200 OK response and deliver notifications to devices. Over time, the frequency of TopicDisallowed responses has been decreasing, leading us to speculate that APNs might be caching responses and updating this cache over time. Questions: Could you provide details on the specific conditions or causes that lead to a TopicDisallowed error? After replacing the certificate, is there a reason why we might still be intermittently receiving this error? Are there additional certificate or configuration settings we should check? What might cause some requests to succeed with a 200 OK response, while others result in a TopicDisallowed error with the same setup? Is it possible that APNs could be caching outdated information from the previous certificate, which might explain the decreasing frequency of the errors? We have reviewed our certificate and configuration after the renewal, but the issue persists. Any guidance on how to further troubleshoot or resolve this would be greatly appreciated. Thank you.