We are implementing a camera intercom calling feature using VoIP Push notifications (PushKit) and LiveCommunicationKit (iOS 17.4+). The app works correctly when running in foreground or background, but fails when the app is completely terminated (killed by user or system). After accepting the call from the system call UI, the app launches but gets stuck on the launch screen and cannot navigate to our custom intercom interface. Environment iOS Version: iOS 17.4+ (testing on latest iOS versions) Xcode Version: Latest version Device: iPhone (tested on multiple devices) Programming Languages: Objective-C + Swift (mixed project) Frameworks Used: PushKit, LiveCommunicationKit (iOS 17.4+) App State When Issue Occurs: Completely terminated/killed Problem Description Expected vs Actual Behavior App State Behavior Foreground ✅ VoIP push → System call UI → User accepts → Navigate to intercom → Works Background ✅ VoIP push → System call UI → User accepts → Navigate to intercom → Works Terminated ❌ VoIP push → System call UI → User accepts → App launches but stuck on splash screen → Cannot navigate Root Issues When app is terminated and user accepts the call: Data Loss: pendingNotificationData stored in memory is lost when app is killed and relaunched Timing Issue: conversationManager(_:perform:) delegate method is called before homeViewController is initialized Lifecycle Confusion: App initialization sequence when launched from terminated state via VoIP push is unclear Code Flow VoIP Push Received (app terminated): func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { let notificationDict = NotificationDataDecode.dataDecode(payloadDict) as? [AnyHashable: Any] let isAppActive = UIApplication.shared.applicationState == .active // Store in memory (PROBLEM: lost when app is killed) pendingNotificationData = isAppActive ? nil : notificationDict if !isAppActive { // Report to LCK try await conversationManager.reportNewIncomingConversation(uuid: uuid, update: update) } completion() } User Accepts Call: func conversationManager(_ manager: ConversationManager, perform action: ConversationAction) { if let joinAction = action as? JoinConversationAction { // PROBLEM: pendingNotificationData is nil (lost) // PROBLEM: homeViewController might not be initialized yet if let pendingData = pendingNotificationData { ModelManager.share().homeViewController.gotoCallNotificationView(pendingData) } joinAction.fulfill(dateConnected: Date()) } } Note: When user taps "Accept" on system UI, LiveCommunicationKit calls conversationManager(_:perform:) delegate method, NOT a manual acceptCall method. Questions for Apple Support App Lifecycle: When VoIP push is received and app is terminated, what is the exact lifecycle? Does app launch in background first, then transition to foreground when user accepts? What is the timing of application:didFinishLaunchingWithOptions: vs pushRegistry:didReceiveIncomingPushWith: vs conversationManager(_:perform:)? State Persistence: What is the recommended way to persist VoIP push data when app is terminated? Should we use UserDefaults, NSKeyedArchiver, or another mechanism? Is there a recommended pattern for this scenario? Initialization Timing: When conversationManager(_:perform:) is called with JoinConversationAction after app launch from terminated state, what is the timing relative to app initialization? Is homeViewController guaranteed to be ready, or should we implement a waiting/retry mechanism? Navigation Pattern: What is the recommended way to navigate to a specific view controller when app is launched from terminated state? Should we: Handle it in application:didFinishLaunchingWithOptions: with launch options? Handle it in conversationManager(_:perform:) delegate method? Use a notification/observer pattern to wait for initialization? Completion Handler: In pushRegistry:didReceiveIncomingPushWith, we call completion() immediately after starting async reportNewIncomingConversation task. Is this correct, or should we wait for the task to complete when app is terminated? Best Practices: Is there a recommended pattern or sample code for integrating LiveCommunicationKit with VoIP push when app is terminated? What are the best practices for handling app state persistence and navigation in this scenario? Attempted Solutions Storing pendingNotificationData in memory → Failed: Data lost when app is killed Checking UIApplication.shared.applicationState → Failed: Doesn't reflect true state during launch Calling gotoCallNotificationView in conversationManager(_:perform:) → Failed: homeViewController not ready Additional Information Singleton pattern: LCKCallManagerSwift, ModelManager homeViewController accessed via ModelManager.share().homeViewController Mixed Objective-C and Swift architecture conversationManager(_:perform:) is called synchronously and must call joinAction.fulfill() or joinAction.fail() Requested Help We need guidance on: Correct app lifecycle handling when VoIP push is received in terminated state How to persist VoIP push data across app launches How to ensure app initialization is complete before navigating Best practices for integrating LiveCommunicationKit with VoIP push when app is terminated Thank you for your assistance!

Hi Team, We are building oru subscrption app and want to rely on server side purchase / subscription related notifications. We went through https://developer.apple.com/documentation/appstoreservernotifications/enabling-app-store-server-notifications We wanted to understand the reliability and latency for server side notifciations provided by Appstore.

Hey there my application allows users to have video calls with each other using Agora. I have successfully set up incoming call functionality on Android but on iOS I am struggling to get the call ui to appear when the app is not running/in background/locked. To my knowledge this is because there is much stricter security on iOS which is limiting me from calling this. When i initially set it up it worked at first when the app was in the background but I think I was failing to report the call to call kit in time and now it's not working. I'm not sure if I need access to this entitlement: com.apple.developer.pushkit.unrestricted-voip Which i believe is only for the big boys or if I make sure I'm reporting the call to call kit fast enough that I won't encounter this issue and it will consistently work in the background.

I’m using iOS 26 beta 9 on my iPhone 15 Plus. When I receive a call from a contact with multiple phone numbers, the call history does not clearly show which specific number was used to call me. Why? How to fix this issue?

Problem Description Location-based notifications added with UNLocationNotificationTrigger and CLCircularRegion do not fire consistently when the user enters the monitored region. Sometimes they work, sometimes they do not. In tests where the user physically enters the region and waits several days, the notification often never triggers. What we’ve confirmed Notification permission is granted Location permission is set to “Always” The notification request is successfully added (no error from UNUserNotificationCenter.add) Pending notification requests are present when checked with getPendingNotificationRequests CLLocationManager didEnterRegion / didExitRegion work when we monitor the same region via startMonitoring(for:) UNLocationNotificationTrigger behavior is inconsistent and unreliable in our tests Reproduction Steps Launch the app and grant notification permission and “Always” location permission Add a region notification (either by current GPS location or by selecting a point from MKLocalSearch) Leave the monitored region Later, physically return into the region Expected: a notification is delivered when entering the region Actual: the notification often does not appear, even after waiting days Our Hypothesis: Coordinate System Mismatch in China We suspect the issue may be related to coordinate systems in mainland China. In China, Apple MapKit and MKLocalSearch use GCJ-02 (the “Mars” coordinate system required by local regulations). Device GPS and CLCircularRegion / Core Location use WGS-84. If an app supplies GCJ-02 coordinates to CLCircularRegion (e.g. from MapKit or search), the region center may be offset by hundreds of meters from the actual WGS-84 position. That could make the system’s “inside region” check fail, even when the user is physically inside the intended area. Questions for Apple Does CLCircularRegion (and therefore UNLocationNotificationTrigger) expect coordinates in WGS-84? If so, should apps in China convert GCJ-02 to WGS-84 before passing coordinates to CLCircularRegion? Is there any official guidance or documentation for handling coordinate systems when using location-based notifications in mainland China? Are there known limitations or special requirements for UNLocationNotificationTrigger in China (e.g. coordinate system, accuracy, or system behavior) that could explain intermittent or missing triggers?

In the main app, is there a way to distinguish whether the application:didFinishLaunchingWithOptions: method is triggered by the user manually clicking the app icon, or whether it is automatically triggered by the system after Live Activities receives a remote message notification?

I have converted a large part of the data, but only 5% of the data was successfully converted. The failed devicetoken shows "bad devicetoken" when accessing APNS. Here are examples of failed conversions devicetoken. Is there any official documentation for this part? DeviceToken Orgin \xc2\xa1\xcb\x9cr\xc3\x81\xe2\x80\x9e\x01b\xc3\xbce1pf\t\xc2\xa7\xc3\x82v}\xc3\xa1\xc3\x9a:?\r\n\xc3\xa5\xc6\x92\xc3\xb7y\xc3\x9e\xe2\x80\x9c\xc3\x89r

We're trying to add simple notifications to our CarPlay integration that should open certain template when pressed, but the issue is that when pressing this notification on CarPlay screen nothing is invoked in the code (presumably didReceive should be invoked). All works fine with the same notification but pressed on the iPhone screen - didReceive is invoked properly. How should I handle the action when push notification is pressed on CarPlay screen?

Hello, I am developing a calling service using CallKit and VOIP push. I have occasionally encountered a strange issue. The issue is that VOIP permanently fails to receive calls. I was previously informed that even if the device is blocked, it can receive calls again after 24 hours. Also, when I checked the device logic, it complied with the policy requirements set by Apple, including correctly calling CallKit's reportNewIncomingCall method. Once the issue occurs, no matter how many times I try, VOIP does not receive calls, and neither a device reboot nor checking the Device Console Log shows any logs related to CallKit or VOIP. I suspect this might be an issue with the VOIP token, and I believe that the only way to get a new one is to reinstall the app. Is that correct? Of course, after reinstalling, it works fine again, but this is very inconvenient. I don't think this is the right solution. Is there anyone who can share their insights on this issue? Thank you.

Hello, We have a Push-to-Talk (PTT) application that is already well established and widely used. Our app has the proper VoIP entitlement, which we are using to wake up the app and establish a WebSocket connection for real-time communication. We are also using CallKit as a supporting mechanism, but not as the primary interaction upon receiving the VoIP Push, since our use case differs from traditional full-duplex VoIP calls. While our implementation works correctly in many cases, we have noticed a consistent issue where, after multiple VoIP Push notifications, the system still delivers the push, but prevents the WebSocket from reconnecting. At this point, all connection attempts return errors such as: • "Software caused connection abort" This issue persists until the app is manually relaunched, after which the behavior resets and repeats. We are aware that VoIP Push was originally designed for full-duplex calls, but since Apple allows its use for other purposes through the entitlement, we would like to understand why this limitation is occurring and how to handle it properly. Questions: 1. Is iOS enforcing stricter background execution rules after multiple VoIP Push events within a short period? 2. Are there any recommended best practices to ensure reliable WebSocket reconnection in this scenario?

sending the following POST request: ---- HTTP REQUEST ---- POST https://appleid.apple.com/auth/token Headers: Content-Type: application/x-www-form-urlencoded Body: client_id=au.com.thejlrguy.businesschat&client_secret=eyJhbGciOiJFUzI1NiIsImtpZCI6IktLUDc4MkhGVTcifQ.eyJ...QeDn7ug&grant_type=client_credentials&scope=https%3A%2F%2Fappleid.apple.com Getting the below error: {"error":"invalid_client"} The private key used to sign the JWT was created 24 hours ago.

Is there a public method to know when an APNS has appeared on the screen? wrapping up a very high end photogrammetry app, using the front facing camera and screen illumination- incoming notifications completely throw off the math. Ideally, it would be great to turn on Do Not Disturb for the short process, but we’d settle for just the detection of the notification banner. also: extra credit - programattically adjusting Auto Dimming, and True Tone would be lovely too.

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?

手机型号：iPhone 13 Pro iOS版本号：iOS 18.6.2 (22G100) 用户开启了应用的系统通知功能，在收到离线推送后应用右上角展示未读消息数。在APP启动或者从后台恢复的时候，应用会用如下方法清理应用桌面图标的未读数角标。但是在部分机型上，应用转为“后台模式”时仍然会出现一个未读角标，且每次都是一个固定值；如果直接kill进程就不会出现未读角标。请问如何能够【完全】清理消息未读数，确保不会在退后台的时候再次出现呢？ [[UIApplication sharedApplication] setApplicationIconBadgeNumber:0]; [[UIApplication sharedApplication] cancelAllLocalNotifications]; if (@available(iOS 16.0, *)) { [[UNUserNotificationCenter currentNotificationCenter] setBadgeCount:0 withCompletionHandler:nil]; [[UNUserNotificationCenter currentNotificationCenter] removeAllPendingNotificationRequests]; [[UNUserNotificationCenter currentNotificationCenter] removeAllPendingNotificationRequests]; } UNMutableNotificationContent *content = [[UNMutableNotificationContent alloc] init]; content.badge = @(-1); UNNotificationRequest *request = [UNNotificationRequest requestWithIdentifier:@"clearBadge" content:content trigger:nil]; [[UNUserNotificationCenter currentNotificationCenter] addNotificationRequest:request withCompletionHandler:^(NSError * _Nullable error) { // Do nothing }];

I wanted to know if Apple ever supported displaying a red dot on notificationswith no indication number.

Is there any information for developer about notification forwarding which is published in iOS 26.3? how to use it ?

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

Hello, I am writing this because the behavior of the App Store Server Notification that our server receives is problematic in the Sandbox environment. I have two questions in total. When purchasing a Free Trial subscription, after receiving the SUBSCRIBED / INITAL_BUY Notification, DID_RENEW should be sent when it expires, but DID_FAIL_TO_RENEW/GRACE_PERIOD is sent. The EXPIRE Notification is sent after the subscription expires or DID_CHANGE_RENEWAL_STATUS/AUTO_RENEW_DISABLED is sent, but it does not arrive. The first problem is that I recently heard that automatic payments after a free trial require the user's consent via email. Is this the reason? If so, I am curious about how I can test it in the Sandbox environment. Is the second problem a bug?

Hi Apple team and fellow developers, We previously had Location Push Service Extension enabled and working in production. After transferring the app to a new Apple Developer team, the production App ID was transferred, but the Location Push entitlement was not retained. We've also created a new App ID for development, and now need Location Push access enabled for both the transferred production ID and the new development ID. We’ve already submitted the Location Push Access form with all relevant details. Unfortunately, the App Transfer documentation didn’t make it clear that Location Push access would be lost, and now we’re blocked from making new builds — even for the existing production app. ❓ Questions: Is it possible to re-enable Location Push for a transferred App ID? What’s the expected timeline for entitlement approval? Can Apple staff confirm the request status or let us know if any further action is needed? Thanks in advance — this entitlement is critical for our app’s functionality and release pipeline. Best, Aidar

I noticed the time sensitive entitlement says it's only for iOS and macOS. But without the entitlement, the time sensitive toggle doesn't show in my app's notification settings on visionOS. When I archive my visionOS app for App Store Connect, the entitlement seems to be taken out as it doesn't show in my entitlement list for the build in App Store Connect. I'm confused at this point if the entitlement is really necessary, since it seems to be needed to debug on the simulator at least. I don't have a physical device to test it on unfortunately.