Hi everyone, I recently migrated my individual Apple Developer account to an Organization account for my company "". My Team ID remained the same. I'm now facing persistent issues with code signing and push notifications for my iOS app (Bundle ID: com.).
 Current Problems:
 "Untitled" Certificates in Xcode: When I go to Xcode -> Settings -> Accounts -> [My Apple ID] -> Select "" Team -> "Manage Certificates...", a number of my newly created Apple Development and Apple Distribution certificates are listed древ "Untitled". Some older ones are "Revoked". (See attached screenshot if possible).
 "No App ID" for Push Notifications Console: In my app target's "Signing & Capabilities" tab, I've added the "Push Notifications" capability. However, when I click the info button to open the "Push Notifications Console", it states: "no app IDs: Register an App ID with the Push Notifications capability enabled to use the Push Notifications console." This is despite the fact that the Push Notifications capability IS enabled for my App ID com. in the Developer Portal, and I've configured an APNs Auth Key (.p8) for it.
 Push Notifications Not Received (from Backend): While I can successfully send a test push notification directly from the Firebase Console to my device's FCM token, notifications triggered by my backend (Firebase Cloud Functions writing to a Firestore collection, which then triggers another function to send via FCM) are not being delivered to iOS devices. (Android seems to be working more reliably now).
 Setup: Using an APNs Authentication Key (.p8) linked to my Organization Team ID in Firebase Cloud Messaging. Main App ID com. has "Push Notifications" capability enabled. Notification Service Extension com..ImageNotification also has its App ID and Provisioning Profile set up for the Organization team. Created new Development and Distribution certificates and Provisioning Profiles specifically for the Organization team. Using "Automatically manage signing" in Xcode with the Organization team selected for both the main app target and the extension target.
 Troubleshooting Done: Revoked old/problematic certificates and profiles. Recreated CSRs and new Development/Distribution certificates under the Organization team multiple times. Recreated Provisioning Profiles. Cleaned Derived Data in Xcode. Ensured Bundle Identifiers are consistent. Verified APNs Auth Key details (Key ID, Team ID) in Firebase.
 I suspect there's a fundamental issue with how Xcode is recognizing or linking the signing assets for my Organization team after the account type change, despite the Team ID being the same. The "Untitled" certificates are a major red flag.
 Has anyone encountered similar issues, particularly the "Untitled" certificates or the "No App ID" message for the Push Console, after an account migration or when working with Organization accounts? Any insights on how to resolve this would be greatly appreciated.
 Thanks,
Benni

Hello! We've had reports of iOS devices 'waking up' and vibrating in response to the push notifications arriving but the notification itself is not being displayed to the user, despite having been granted the correct permissions. Is this a known issue?

I’m getting calls from Pakistan every hour. I cant block them because it’s a different number every time. I have downloaded the new beta version of the upcoming software update and it allows you to set to ask a question before unknown callers ring through. It’s not working and my phone is constantly ringing. I can’t block unknown callers as I use my phone for work. How can I silence ringing from calls specifically from Pakistan Using the country code?

When subscription renewing , can do purchase_date faster than notification_date quickly? I received my app user purchase notification this purchase date is 2025-08-31 06:42:54(UTC) but notification date is 2025-08-30 22:45:01(UTC) how can you do this? I can't understand it please let me explain

Version: iOS 18.1 and later (works as expected on iOS 18.0 and earlier) Area: SpringBoard / Notification Center / App Icon Rendering Description: When changing the app's alternate icon using UIApplication.setAlternateIconName(_:completionHandler:), the icon is updated correctly on the Home Screen and App Switcher. However, in Notification Center, the old app icon is still shown for notifications, even after the change has completed. This issue only occurs on iOS 18.1 and later. In iOS 18.0 and earlier, Notification Center correctly reflects the updated icon. - Steps to reproduce: Create an iOS app with alternate app icons configured in the Info.plist. Use UIApplication.shared.setAlternateIconName("IconName") to change the icon at runtime. Send a notification. Pull down Notification Center and observe the icon shown beside the notification. - Expected Behavior: Notification Center should reflect the updated (alternate) app icon immediately after the change. - Actual Behavior: Notification Center continues to display the old (primary) app icon. The new icon appears correctly on the Home Screen and App Switcher. Restarting the device does cause Notification Center to update and reflect the correct icon, which suggests a cache or refresh issue in SpringBoard or Notification Center. - Notes: Issue introduced in iOS 18.1; not present in 18.0. Reproduces on both physical devices and simulators. Occurs with both scheduled local notifications and remote notifications. Restarting the device updates the Notification Center icon, but this is not a viable user-facing workaround.

I want to update my lockscreen LiveActivity via Broadcast Push Notification, but updating always fails - but ending always works. Payload with "update" is completely ignored: {"aps":{"timestamp":1685952000,"event":"update","content-state":{"currentSlotName":"Debug1","nextSlotName":"Debug2"}}} Same payload with "end" works, the view is refreshed with the new content-state: {"aps":{"timestamp":1685952000,"event":"end","content-state":{"currentSlotName":"Debug1","nextSlotName":"Debug2"}}} Via the MacOS Console I am able to see that both events happen to end up on the device. I am sending these Broadcast Push Notifications via Apple's Push Notifications Console.

I am an iOS development engineer. Recently, I updated the Xcode version to 16.1 (16B40) and updated my debugging device (iPhone 15) to iOS 18.1.1. However, I found that I could not respond to the delegate method. I confirmed that my code, certificate, Xcode settings, and network environment had not changed. Simply executing application.registerForRemoteNotifications() in func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool did not receive a response(didRegisterForRemoteNotificationsWithDeviceToken or didFailToRegisterForRemoteNotificationsWithError ). In the same environment, when I switched to another device for debugging (iOS 17.0.3), the delegate method would respond. I really don't know what to do, I hope someone can help me, I would be very grateful. Please note: Everything is normal when using devices before iOS 18.1.1 version

I’m using Appnotic from my server to send notifications for an emergency service, where it is critical that notifications are delivered immediately. My payload looks like this: "aps": { "alert": "Test alert", "sound": { "critical": 1, "name": "sound.wav", "volume": 0.5 }, "content-available": 1, "category": "alert" }, "topic": "com.fireservicerota.FSR-Primary-Alerting", "custom_payload": { "id": "11", "type": "alert", "incident_id": 23434, "incident_response_id": 2652343, "expiration_time": "2024-06-06T16:59:05+01:00" } } I already have the critical alert entitlement and background processing enabled. Everything seems fine when debugging, but I’m experiencing issues: • Some notifications never arrive • Around 60% of notifications arrive with noticeable delay Since this is an emergency app, delivery speed is crucial. What could be causing this inconsistency?

I'm working on implementing Apple Wallet passes using background push notifications. My server successfully sends the push notification using APNs. The response from the server is HTTP/2 200, and the device receives the push — I can confirm this from device logs. However, the device logs show the following error: "Failed to parse JSON message payload for topic " "Unable to deserialize JSON message payload" My payload is below 2 payload. //string payload = "{"aps":{"content-available":1}}"; string payload = JsonConvert.SerializeObject(new { aps = new Dictionary<string, object> { { "content-available", 1 } } }); string curlArgs = $"-s -o nul -w \"%{{http_code}}\" " + $"--data-binary \"{payload}\" " + $"-H \"apns-topic: {bundleId}\" " + $"-H \"apns-push-type: background\" " + $"-H \"apns-priority: 5\" " + $"-H \"content-type: application/json\" " + $"-H \"authorization: bearer {jwt}\" " + $"--http2 https://api.push.apple.com/3/device/{token}"; I’ve confirmed that: The device has the Wallet pass installed. The apns-topic header is set to my passTypeIdentifier. The apns-push-type is background and apns-priority is 5. Steps to Reproduce: Install Wallet pass on iOS device. Send background push to device using the above payload. Observe the device logs using Console.app or log stream. See error: unable to deserialize JSON message payload. Is there a specific payload format expected for Wallet passes? Or any additional fields required in the push payload to avoid this deserialization error?

Hi all, We encountered an issue where APNs (Apple Push Notification service) push messages cannot be received during development. The specific description is as follows: Our app runs on an iPad that connects to the cellular network using a SIM card and accesses the Internet through the company's MDM, which provides APN setting proxies. During operation, we found that the device fails to receive push messages from APNs. Network packet capture revealed that the connection attempt by apsd to port 5223 failed. According to Apple's documentation (https://support.apple.com/zh-cn/102266), when port 5223 cannot be connected to, it will fall back to port 443 and use a proxy. However, our packet capture showed that when port 5223 was unreachable, the apsd service on the iPad did not attempt to establish a connection to port 443. Since the iPad device currently cannot establish a connection with APNs, it consistently fails to receive push messages from APNs. We tried disconnecting the SIM card and using a Wi-Fi environment, and in this case, the iPad device was able to receive push messages from APNs normally. Could you advise us on how to proceed with troubleshooting in this situation?

Hello everyone, Our team is currently developing a PTT (Push-to-Talk) application using the officially recommended PushToTalk framework. During development, we've encountered a point of confusion regarding the application's behavior after being force-quit by the user. Based on our understanding of the PushToTalk framework documentation (https://developer.apple.com/documentation/pushtotalk/creating-a-push-to-talk-app/) and the PTChannelManager session restoration mechanism, when a user manually kills the app from the background (App Switcher), the current PTT session (the system session managed by PTChannelManager) should terminate. Subsequent pushtotalk type pushes sent via APNS, without an active session, appear to be silently discarded by the system and cannot wake the app for processing (similar to what Kevin Elliott DTS mentioned in https://developer.apple.com/forums/thread/760506 Point D). This seems to prevent reliable PTT message reception in our app after a user force quits. However, we've observed that some popular PTT applications on the market (e.g., TenTen) appear to successfully receive and play PTT voice messages from friends even after the user has performed a force-quit action. This behavior seems inconsistent with our test results and understanding based on the standard framework, posing a challenge for us in providing similar reliability using standard methods. This naturally leads us to wonder how this capability is achieved. We've reviewed developer forums and are aware of the historical existence of a PTT-specific com.apple.developer.pushkit.unrestricted-voip entitlement, which allowed PushKit usage for PTT without CallKit binding. While Apple DTS engineers have repeatedly stated this entitlement is being deprecated and urged migration to the PushToTalk framework (e.g., https://developer.apple.com/forums/thread/763289), we are curious if the observed "wake-after-force-quit" capability might be related to some apps potentially still utilizing this outgoing special entitlement. Alternatively, is there perhaps a mechanism within the standard PushToTalk framework that allows wake-up after force quit that we haven't fully grasped? Therefore, we'd like to ask fellow developers for clarification and discussion: When using the standard PushToTalk framework, have others confirmed that the app indeed cannot be woken up by pushtotalk pushes after being force-quit by the user? Is this the expected behavior? Has anyone successfully achieved a TenTen-like experience (reliable PTT reception after force quit) using only the standard PushToTalk framework? If so, could you share key implementation insights or areas to focus on? (e.g., Is it related to specific usage patterns of the restorationDelegate?) How do you view this potential discrepancy between standard framework capabilities and the behavior exhibited by some apps? What considerations does this bring to development planning and user experience design (especially when users might have expectations set by the "always-on" behavior of other apps)? Are there any best practices or specific techniques when using PTChannelManager session management and restoration that maximize PTT message reliability (especially after the app is terminated by the system in the background), while still adhering to the framework's design principles (like user awareness of the session via UI)? [For instance, another developer raised challenges related to PTT framework restrictions here: https://developer.apple.com/forums/thread/773981] We hope this discussion can help clarify our understanding of the framework and gather community best practices for building reliable PTT functionality while adhering to Apple's guidelines. Thanks for any insights or shared experiences!

The following issue has occurred: Push notifications are not being received on certain devices. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving normal responses from APNs. Users have confirmed that notifications are enabled on their devices, and they report no network issues. This problem is occurring for multiple users.

iOS push notification is not working for in App since 03-Apr-2025. We are pushing the message to APNS from our application, but message is not delivered to iOS device. We have performed tests on both PROD and QA environment and following are the observations: PROD successfully pushing the notification to APNS but not receiving the notification on iOS device (100% failure). QA received notification on iOS device always (100% success). Analyzed PROD notification server log at our end and we do not observe any error and it is showing successful also when message is pushed to APNS all the time. Need to check from APNS why push messages are not delivered to iOS devices. Validated the PROD APNS certificate at our end which we are using during call to APNS - it is valid till Oct 2025. Please suggest me any possible solution because I don't have any clue where it is failing and what to do

I'm encountering an issue with our legacy Objective-C codebase that uses UIApplicationDelegate. Here are the steps to reproduce the issue: Uninstall the application from the device. Install and launch the application. As part of the launch event, the client requests notification permission. The permission prompt is still displayed, even though the client receives a remote notification token (which appears to be a cached one). I followed the same steps with a sample app built with Swift (SwiftUI), and this issue did not occur. In the Swift app, I consistently received a delegate<didRegisterForRemoteNotificationsWithDeviceToken> call after the user allowed the notification permission. Could you please provide some insights into why this might be happening with only our client?

Hey Together, I have seen that critical notifications need to be confirmed by apple to be used. Sadly I couldn't figure out where to ask for that. Context: I have a sports tournament app for Beach Handball. There are a couple of Courts like up to 20-25. The main use for that in my app would be to notify first aiders/Medics. Right now they are called in via Speakers or by the referees just writing that into a WhatsApp chat. As this takes a long time and the speakers can be deactivated due to rain, power shortage or even the medics sometimes are not in range to exactly hear the speakers calling them. To Speed up this process I want them to download the App, Register via an E-Mail or a One Time Code. Now if a referee needs immediate Help from the Medics on their court they can send the Critical alert to the Medics without having to write a chat into a WhatsApp group, to get a call through the speakers 10 minutes later which the medics may not even hear. A couple of weeks ago we had a player falling on her back/neck/head and they couldn't figure out if she broke her neck or not. Luckily the medics were right next to the court and saw that. but what would happen if they were a couple hundred of meters away and did not notice that? I mean the PA system was off due to a power shortage. someone trying to move her? Risking her death? And while we are at it we could add those notifications if a team is missing to a court for a game that already should've started. Critical because it is urgent. Those notifications are handled with care.

when I implementation the UNUserNotificationCenterDelegate func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -&gt; Void) { var status = "" if (UIApplication.shared.applicationState == .active) { status = "active" } else if (UIApplication.shared.applicationState == .background) { status = "background" } else if (UIApplication.shared.applicationState == .inactive) { status = "inactive" } completionHandler() } I find that UIApplication.shared.applicationState == .background this case can not execute when application is in background。 why applicationState is inactive not background?

Hello, I am working on a project that involves using external device to connect over BLE with users iPhone. I would like to be able to notify users on our device about eg. incoming calls, messages etc. I have been succesfull in using ANCS to achieve that but I am a little worried around consistency of this solution, especially taking into account following line from documentation: Due to the nature of iOS, the ANCS is not guaranteed to always be present. As a result, the NC should look for and subscribe to the Service Changed characteristic of the GATT service in order to monitor for the potential publishing and unpublishing of the ANCS at any time. I have not been able (yet?) to find or identify circumstances when ANCS would not be avilable or would be "removed in runtime", hence would it be possible to request some guidance and clarification on the conditions when ANCS can be unavailable or removed? Thank you!

We're experiencing an issue with Apple Push Notification service where APNs continues to return 200 OK responses for device tokens belonging to uninstalled applications. Issue Details: When sending push notifications to device tokens. APNs returns 200 OK responses even for devices where our app was uninstalled more than a month ago According to documentation(https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns), APNs should return 410 status code with JSON body for invalid tokens Expected Behavior: APNs should return 410 status code when device token is no longer valid (app uninstalled) Thanks in advanced for support

Hey everyone! I'm trying to develop an app that would need to send periodic notifications (every 20 minutes, for instance) to the user even when the app is not running (but only when the phone is being used). I've been reading through the prior comments and all about not being able to have a timer run in the background in the way I need it to, but I wanted to ask if there's any way around this, or is there truly no way? If there is no way to do this, I was just now considering another workaround, where I could try getting the time they open their phone, and from there, I schedule local notification for every 20 minutes or so for the entire day, and they keep sending until the phone is turned off, when the rest of the scheduled local notifications are cancelled. Is this possible? I would also appreciate any other suggests/workarounds for this. Happy to provide any additional details needed! Thanks!

Hi, We have a simple calendar reminder app that uses UNNotificationRequest to schedule local notifications for user events. I’m wondering whether UNNotificationRequest has a system-imposed limit of 64 upcoming scheduled notifications, similar to the deprecated UILocalNotification. We’re asking because one of our users is not receiving recently scheduled reminders. Our current workflow is: We schedule notifications on app launch and when the app is about to quit. Before scheduling, we call removeAllPendingNotificationRequests(). We then fetch the 64 nearest upcoming events and schedule them using UNUserNotificationCenter.current().add(...). This approach works fine during our testing, but we’re unsure what might be causing the issue for some users. Any insights would be appreciated. Thanks!