@AJAS_M_M My app, which was stuck in Apple's review process as mentioned. After that my App rejected multiple times due to the complex login procedure of my app requiring additional further explanation. However, it was finally approved on February 18, 2026. Regarding Apple's comment on January 26th: "Thank you for your post. We're investigating and will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us." I actually followed the link provided there and requested an "expedited app review" by navigating to "contact us > Get help with a new issue > App Review > request an expedited app review". Based on my experience, I believe this is the only thing we can do on our end in such situations. I hope your review process concludes successfully as well.

Hi Quinn, Thank you for your excellent advice! I followed your guidance, specifically by enabling "Automatically manage signing" in Xcode's "Signing & Capabilities" settings and conducting an overall review of my Xcode configuration. I'm pleased to report that I've now successfully built the application. Your assistance was greatly appreciated.

Dear Quinn, In February 2021, when an Entitlement was added to Team ID WEJZZZZZZZ, I received the following email from Apple and learned how to add the Entitlement to a provisioning profile: Hi, Does Apple add entitlement to my team ? (== App ID: WEJZZZZZZZ) Yes, the entitlement was actually added to your “team”. That gives you the ability to add the entitlement to any app that’s managed by your “team”. Here is the configuration information you can use to check the current status and/or configure your own project: -To use the entitlement, you need to codesign your app with a provisioning profile that includes it. In the Apple developer portal website, you’ll need >to do the following: In the “Provisioning Profiles” section, click the “+” and to create a new profile In the “What type of provisioning profile do you need?” section, select “iOS App Development” Walk through the creation process and directly after the “Select devices.” section, you should see a new section titled “Do you need additional ent>itlements?”. In the new section, there is an “Entitlements:” popup, which will include list the new entitlement. …and continue the process from there to generate the necessary provisioning profile. To use the profile in your project, this is the process I recommend -(Omission) - Best Regards, Apple Developer Relations This time, an Entitlement has been added to Team ID NWKYYYYYYY. Has the method for adding the Entitlement to a provisioning profile changed since February 2021? I have tried the same method, but the "new section" mentioned in "4) In the new section, there is an “Entitlements:” popup, which will include list the new entitlement." does not appear for Team ID NWKYYYYYYY. NEAppPushProvider. In Xcode’s Signing & Capabilities editor, it should show up as Network Extension (additional values). Likewise in the App ID editor on the Developer website. If there have been changes to the procedure and the above operation is now required for Team ID NWKYYYYYYY, please provide detailed instructions.

Dear Sir/Madam, I apologize. There was an error in my previous question, and I'm correcting it. The correct information is as follows: Team ID SV3XXXXXXX Entitlements: Present. Approved for Entitlements on April 28, 2021. (Received "Re: Requesting Network Extension App Push Entitlement" email on April 28, 2021) Team ID NWKYYYYYYY Entitlements: Not present. Approved for Entitlements on March 13, 2026. (Received "Re: Requesting Network Extension App Push Entitlement" email on March 13, 2026) Team ID WEJZZZZZZZ Entitlements: Present. Approved for Entitlements on February 6, 2021. (Received "Re: Requesting Network Extension App Push Entitlement" email on February 6, 2021) In my initial question, I stated that for WEJZZZZZZZ, there was "No record (email) of applying for Entitlements," but this was incorrect, as it turns out approval was granted. I apologize for the correction. However, my question remains the same: Will the Entitlements field for Team ID NWKYYYYYYY be added if I simply wait? The permissions haven't become active even though approval was completed 5 days ago. Is it just taking some time for them to become active? Thank you for your assistance.

Hi Kevin Thanks for your reply. If the issue has been fixed in 26.3, we are so happy. we can safely continue using it. I haven't filed a bug report yet, but would you recommend I do? Best Regards,

Thank you for your advice. I have resolved the initial issue, but when I use a generic setting, "SNS Profile" is displayed as the title for "No Caller ID" calls. Is there a way to make the title more natural for an "No Caller ID" incoming call?

Hi Thank you for your response. Yes, please file a bug on this and post the bug number back here. Understood. I have posted a bug report. The bug number is FB21409407. Is there some reason you're not just using "Unknown Caller" for this case? Are you asking if there's a reason we're not setting "Unknown Caller" in update.localizedCallerName? If so, the answer is as follows: Answer: To keep the explanation concise, I did not mention this point in the previous descriptions. However, in all the tests I've described so far, update.localizedCallerName has consistently been set to "非通知 (Unknown Caller)" in Japanese. Best Regards, Toshiyuki

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,

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

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.

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.

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?

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.