This only occurs in specific environments. Our app is used by many customers, but this is the first time we've detected this issue, and it's only happened once.

Purpose To clarify previous inquiries, we have reorganized our questions regarding the App Transfer of our VoIP PUSH enabled application "PhoneApp" to another company's (Company B) App Store account. Our goal is to understand the potential impact on existing users and the feasibility of conducting tests of the transfer process. Current Status App Store Publication: "PhoneApp (signed with Company A's certificate)" is currently published by Company A on the App Store. Our PUSH Server: Our PUSH server uses an APNs Authentication Key (P8 Key: Company A) to send PUSH notifications to the Apple Push Notification service (APNs). Existing Users: Existing users receive VoIP PUSH notifications from "our PUSH server (using P8 Key: Company A)" on their iPhones with "PhoneApp (signed with Company A's certificate)" installed. Q1.Regarding Continued Usage by Existing Users After PhoneApp is transferred to Company B and "PhoneApp (signed with Company B's certificate)" is published on the App Store, existing users will continue to use "PhoneApp (signed with Company A's certificate)" until they update the app. In this scenario, will "PhoneApp (signed with Company A's certificate)" on existing users' devices still be able to receive VoIP PUSH notifications from "our PUSH server (using P8 Key: Company A)" as before? We are concerned that all users might need to update their apps to "PhoneApp (signed with Company B's certificate)" simultaneously with the transfer, or that all PUSH servers might need to update their P8 Keys to "P8 Key: Company B" at the same time. This would be difficult to manage. Q2. Regarding Smooth Transition for Existing Users There will be a coexistence period where existing user environments will have both "PhoneApp (signed with Company A's certificate)" and "PhoneApp (signed with Company B's certificate)". We believe that by enabling the following functionalities in our PUSH server, we can ensure that customer operations are unaffected during this coexistence period. Is this understanding correct? Are there any other recommended best practices? When our PUSH server sends a VoIP PUSH to "PhoneApp (signed with Company A's certificate)", it makes a PUSH request to APNs using Company A's APNs Authentication Key (P8 Key: Company A). When our PUSH server sends a VoIP PUSH to "PhoneApp (signed with Company B's certificate)", it makes a PUSH request to APNs using Company B's APNs Authentication Key (P8 Key: Company B). Q3. Regarding Feasibility of Transfer Testing We believed that by temporarily maintaining the following state, we can conduct transfer tests in advance. is this impossible? I have received an answer to this question once, but I would like to re-question I am concerned that there may have been a misunderstanding for my question: Initiate the transfer of "PhoneApp" from Company A to Company B. Company B's Apple Account does not accept the transfer, maintaining a "Pending App Transfer" status. Build "PhoneApp (signed with Company B's certificate) with same bundle ID" and publish it on Company B's Apple Account via TestFlight. Install "PhoneApp (signed with Company B's certificate)" via TestFlight on test devices. The PUSH server sends a PUSH request to "PhoneApp (signed with Company B's certificate)" using "Company B's P8 Key". if above is possible, While maintaining this "Pending App Transfer" status, is it possible to perform the following transfer tests? Receive VoIP PUSH notifications using "Company B's P8 Key" on "PhoneApp (signed with Company B's certificate)". Receive VoIP PUSH notifications using "Company A's P8 Key" on existing "PhoneApp (signed with Company A's certificate)". Receive VoIP PUSH notifications using "Company A's P8 Key" on a newly installed "PhoneApp (signed with Company A's certificate)". (We also want to confirm if "PhoneApp (signed with Company A's certificate)" can still be newly installed from the App Store once the transfer process begins.)

The recipient can build their push servers and test it with another app they own, but not with the transferring app until the transfer is completed. Thank you for your previous guidance. I understood that a recipient can build their push servers and test them with another app they own, but not with the transferring app until the transfer is completed. Based on this, my plan is to first register a new app specifically for PUSH testing under the transferor's account (Company A), confirm that PUSH works, then transfer this test app to the transferee (Company B), and finally, verify PUSH functionality again after the transfer is complete. Now, I have a more specific question regarding the transfer of an existing app. For clarity, let's refer to the transferor's company as Company A, the transferee's company as Company B, and the app to be transferred as App C. Currently, App C (owned by Company A) is widely used by many users who have it installed on their devices. My primary concern is to understand what happens to these existing users' VoIP push functionality when App C is formally transferred from Company A to Company B (meaning, an App Transfer within the Apple Developer Program). Here's my specific question: After App C's ownership is transferred from Company A to Company B, will users who had Company A's App C installed on their devices (before the transfer was completed) still be able to receive VoIP push notifications sent from Company A using Company A's P8 key? My current understanding and proposed setup are as follows: I acknowledge that the P8 key for VoIP push is specific to each developer account (Team ID). So, Company A has its own P8 key, and Company B will have its own P8 key. Therefore, I plan to place Company A's P8 key and Company B's P8 key on the push server, and add a feature that uses Company A's P8 key when pushing to Company A's app C, and Company B's P8 key when pushing to Company B's app C. Because I believe that even after App C is transferred to Company B, users who installed the original App C (signed by Company A) will still be able to receive VoIP push messages if these messages are sent from Company A's push server using Company A's P8 key. Is this assumption correct? Or will the APNs server, upon completion of after the transfer, reject push requests from Company A (using Company A's P8 key) directed at the App C (even if users have the original Company A-signed version installed)? My main concern stems from this: If it's not possible for Company A to continue pushing to the existing installed base after the transfer, it would imply that all existing users would immediately lose push functionality from the moment the app transfer is completed. To regain functionality, they would then need to update their app to a version signed by Company B. This burden (requiring immediate updates from a large user base to maintain core functionality) would be significant and could cause considerable confusion. Could you please clarify the exact behavior of APNs in such an app transfer scenario, specifically regarding the continued validity of the original owner's P8 key for previously installed app versions? If my assumption is incorrect, I would greatly appreciate any guidance or recommended workarounds to mitigate the disruption for existing users during and after an app transfer. Thank you for your time and assistance.

Thank you for your previous response to my question which directed me to the Extra-ordinary Networking documentation. We have thoroughly reviewed this documentation and related articles, but have yet to find a direct solution to the specific problem we are facing. Our VoIP application is currently being operated in a customer environment utilizing an sXGP-SIM (local LTE-SIM). A specific requirement from our customer is to "always use the data communication network, rather than the voice call-specific VoLTE network, for establishing SIP and RTP traffic." What we know from our investigations so far: In the customer's sXGP environment, we have confirmed that the VoIP application (client) can successfully connect to the SIP server (server) and conduct VoIP calls (RTP), regardless of whether the connection routes through what might be conceived as a VoLTE network or a general data communication network. Following general best practices, we considered an approach where we do not explicitly call bind() when creating sockets, but instead rely on the OS for route selection (i.e., using connect() and then getsockname() to retrieve the local IP address). However, with this method, we believe it is not possible to control whether the OS-selected route becomes a VoLTE network or a data communication network, nor is it possible for the application to programmatically identify the type of network used. Given that both presumed network paths are viable for reaching the target server in the customer's environment, we cannot rule out the possibility of the OS selecting a VoLTE network path. We are seeking clarification on the following two points: 1. Identification of VoLTE vs. Data Communication Network Is there an existing iOS API (including Network Extension Framework, Network.framework, or other lower-level APIs) that allows an application to programmatically determine whether the current network path is a logical path assigned for VoLTE, or a logical path assigned for general data communication? 2. Forcing Traffic Routing to a Specific Network Path Similarly, is there an API or mechanism that allows a VoIP application to explicitly force its SIP and RTP traffic to route through a path identified as a "data communication network" and not a VoLTE network? Our team understands that implementing these features via public iOS APIs might be challenging. However, to provide a definitive answer to our customer, an official statement from Apple, especially confirming if "it's currently not feasible with iOS APIs," would be highly valuable as evidence for guiding our future development and customer communication. If such APIs or recommended design patterns do not exist, a clear confirmation of this would be greatly appreciated. Conversely, if it is indeed possible, could you please provide hints on the specific APIs or approaches? Thank you for your time and consideration.

Hi. Thank you for your advice. We will try it.

By "managed environments," I assumed you meant MDM, is that correct? If so, it depends on the client. (We have multiple clients and it varies by client) So, if there is any solution that is based on the premise of "using it in an MDM environment," I would like to know detail of about it.

Thank you for your advice. I understood the usefulness of NEAppPushProvider.handleTimerEvent(). but I found the following description in "Establish and Monitor the Network Connection" Your push provider must implement the handleTimerEvent callback method, which the framework calls every 60 seconds. Implement this method to check the status of the connection on the client end. Is the execution interval of NEAppPushProvider.handleTimerEvent fixed at 60 seconds? If it can be set to an arbitrary interval, would you tell me sample source or how to configure it.

Thank you for the advice. Following your advice, I executed PKPushRegistry on the first line of didFinishLaunchingWithOptions, and that resolved the issue. This was an experimental implementation, but we will proceed with the commercial implementation with the policy of performing PKPushRegistry as early as possible. By the way, why was it necessary to perform PKPushRegistry as early as possible? If it's not too much trouble, could you please tell me?

Since then, I have repeated the test, but the same problem has not recurred, and I have not been able to take a diagnostic log. I don't think we can investigate without the log, but could you let me know there was a similar reports or not before? Best Regards,

The method "[AppDelegateImpl voipRegistration]" is where your app creates and configures PKPushRegistry. Yes, that's correct. "[AppDelegateImpl voipRegistration]" is a log indicating that sequence number 3(PKPushRegistry) in BAADCA11.jpg was executed. The fact that it was not logged indicates that it was never called. Yes, that's correct. myApp executes the PKPushRegistry only once, at sequence number 3 in BAADCA11.jpg. I assume this is what you mean by "PKPushRegistry call for PID 405." After sequence number 3, myApp does not make any PKPushRegistry calls (it doesn't make multiple PKPushRegistry calls). The combination of 1 & 2 would mean that the termination of 512/513/514 was valid. No, I don't think so. I believe this is where our understanding differs. I believe that PKPushRegistry is an API that should be called only once when myApp starts, and not an API that should be called on a call-by-call basis of VoIP . Perhaps you think that PKPushRegistry is an API that should be called on a call-by-call basis? From here on, this is my speculation. Internally in iOS, PIDs 512, 513, and 514 may need to hold the callback destination for PKPush. However, this holding is the result of registration through the interface between internal iOS components. In the interface between iOS and the application, registering only once at myApp launch should definitely be sufficient. Could you please confirm this point and provide the results?

Regarding the key differences between the logs of PID 405 and the logs mentioned above, it appears that they demonstrate the results of repeated each incoming call tests performed after the app was launched. For more details, I have uploaded VID_20250407_111252.mp4 to FB17345744. Please refer to it. As you can see in VID_20250407_111252.mp4, I made five outgoing call attempts (incoming calls on the test device) when I obtained "FjSoftPhone-2025-04-07-1113XX.ips." Based on the iPhone's time display, these operations occurred around 11:12-11:13 (around 0:00:00-0:00:52 in the video timestamp). I believe that 0xBAADCA11 occurred during the first, second, and third incoming calls, and the fourth and fifth incoming calls were ignored. Finally, when Wi-Fi was turned OFF (around 0:01:14 in the video timestamp), the app detected the incoming ghost call with a delay (around 0:01:19 in the video timestamp). Here's a summary of the operations and their timestamps: [Operation Time][Video Timestamp][Operation] [04/07 11:12] [0:00:02] [Caller: Make call (1) ] [04/07 11:13] [0:00:16] [Caller: Make call (2) ] [04/07 11:13] [0:00:28] [Caller: Make call (3) ] [04/07 11:13] [0:00:40] [Caller: Make call (4) ] [04/07 11:13] [0:00:52] [Caller: Make call (5) ] [04/07 11:14] [0:01:14] [Callee: Wi-Fi OFF ] [04/07 11:14] [0:01:19] [Callee: Accept ghost call] I Wrote the app's operation sequence in "BAADCA11.jpg"( attachment file of this incident). Could you please review this sequence and let me know if there are any deficiencies in the app's processing? linkText

The direct cause of the crash is that your app never registed a PushKit handler with callservicesd. You can confirm this by searching for the string "Registering client process" logged by callservicesd. Here is what's logged by an early run of your app (pid=405): The application log shows that the following operations were performed at the following times. What else should the app do to register a PushKit handler with callservicesd? time:04/07 11:10:50.666 operations: dispatch_queue_t mainQueue = dispatch_get_main_queue(); // Create a push registry object voipRegistry = [[PKPushRegistry alloc] initWithQueue: mainQueue]; // Set the registry's delegate to self voipRegistry.delegate = self; // Set the push type to VoIP voipRegistry.desiredPushTypes = [NSSet setWithObject:PKPushTypeVoIP]; Reference sample source: https://developer.apple.com/documentation/pushkit/pkpushregistry?language=objc ...my recommendation is that voip apps should create their basic call handling "infrastructure" as early as possible (typically, applicationDidFinishLaunching) AND that the "core" component should be able to FULLY process a call without ANY of the rest of your app functioning at all. I understood this advice to mean that when you receive a push signal, you should end the push signal reception process in your app as quickly as possible. In this specific incident, the app is not receiving a push signal, so it cannot end the push signal reception process in the app as quickly as possible. Did this advice mean something different?

Thank you for your response. Have you looked at exactly what happens when your app launches in that configuration? I don't see how this would change the systems routing for pushes, but I could see it distorting your apps own network logic. Are you asking about the behavior of the app when WiFi is ON (when it crashes)? I have checked exactly how the app works when WiFi is ON (when it crashes). Application life sycle didn't start when it. iOS didn't call application after push. I haven't checked exactly how the app works when Wi-Fi is OFF, because there are no problems. Also, how is the app being distributed to the device? I do not that there are extra verification steps for enterprise apps and, in theory, it's possible that issues with that verification process could delay the app launch long enough that callservicesd then terminates the app. This application is distributing via App Store(And I tested TestFlight version). You can either file a bug and post the number back here, or you can file a code level support request and send them through email. I reported(and attached logs) about this to Feedback assistant. Number is FB17345744. Would you take a logs from above report?

An app setup like this will work fine under basic testing because the developer/user habitually logs in as soon as they open the app. However, it will be terminated under real world conditions when the system or the user kills the app. The system correctly launches the app into the background, then terminates it because the app is blocked at #1 and has not created a PKPushRegistry object. The crash at step 8 of [Operation] in the initial explanation only occurs when implementing sXGP-SIM. There is no problem when using LTE-SIM(with the same operation perfectly.) If Wi-Fi is enabled when the LTE-SIM is implemented, the crash that in step 8 of the [Operation] in the first explanation will not occur 100%. If Wi-Fi is enabled when the sXGP-SIM is implemented, the crash that in step 8 of the [Operation] in the first explanation will occur 100%. In other words, the problem is not occurring because there is a difference in the app's executing route when a push message is received after the developer/user opens the app and when a push message is received after the app is terminated. What does that crash log show? I'm happy to take a look if you post the log, but my guess is that it will show one of three things: my crash log was below. code:0xBAADCA11 explanation: Is there a way to send the logs other than uploading them directly here? If not, I would like to refrain from uploading logs that include the app name to a public site, Is it okay if I hide(Change the app name to ***, etc.) the app name in the logs? my recommendation is that voip apps should create their basic call handling "infrastructure" as early as possible (typically, applicationDidFinishLaunching) AND that the "core" component should be able to FULLY process a call without ANY of the rest of your app functioning at all. I see your point. We understand that my app needs to be processed as quickly as possible. However in my case, app doesn't get first entry(didReceiveIncomingPushWithPayload). So app can't do anythig...

I have opened FB16493124 in the feedback assistant regarding this issue. Could you please let me know at here also if you found something.