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.)

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.

What thread does the timer target? The simplest way to delay timer firing is to block the runloop the timer is targeting. Sometimes this delays occur, and sometimes they don't. Think of timers as targeting a dedicated call-controll processing thread and not blocking the run loop. Have you set NSTimer.tolerance? While the documentation says that it defaults to "0", I'd suggest setting it to "0" yourself (assuming that what you want). I also considered NSTimer.tolerance and, as per your suggestion, explicitly set it to 0. However, this had no discernible effect, likely because its default value is already 0. Given this, do you have any other suggestions for ensuring reliable timer firing?

Yes. Currently, one of our corporate clients has reported an issue with my application. Upon analyzing the application log file from when the incident occurred, we identified "ENOTCONN" as the cause. We have not received similar reports from other clients. The total number of logs received is limited, and at this time we have only been able to identify the cause from the app logs in one case.

Thank you for your advice. In the end, we decided to address the issue by changing the timer setting to a value that took into account the delays we had observed so far. This issue can be closed.

Thank you for your reply. If this problem occurs again and I am able to get a sysdiagnose, I will contact you again.

Dear Apple Support Team, Hope you are doing well. Regarding my previous inquiry, it was quite extensive and contained some inaccuracies. Therefore, I have re-organized and separated the questions for clarity and would like to confirm them again. We are writing to you regarding an inquiry about the upcoming transfer of our phone application to another company. Our main question is: After this transfer, will our customers' existing systems still be able to continue using the former application as is, for a certain period? Specifically, we want to confirm if the application, once transferred to Co.B, can still be used by our current customers on their existing systems without any immediate changes or issues from Apple's side. Please refer to the attached document for more details. Thank you for your time and assistance. Sincerely,