@Praveen_dharman Thank you very much for your clarification. That answers my technical questions and is extremely helpful. I have one follow-up question regarding App Store submission requirements. I realize this may be outside the scope of the original discussion, but I would appreciate any guidance you can provide. Historically, Apple has required apps submitted to App Store Connect to be built with the latest major SDK beginning around late April of the following year. For example: iOS 17 SDK (Xcode 15): Required starting April 29, 2024 iOS 18 SDK (Xcode 16): Required starting April 24, 2025 iOS 26 SDK (Xcode 26): Required starting April 28, 2026 References 2024 App Store submission requirement: https://developer.apple.com/news/upcoming-requirements/?id=04292024a 2025 App Store submission requirement: https://developer.apple.com/news/?id=9s0rgdy9 2026 App Store submission requirement: https://developer.apple.com/news/upcoming-requirements/ At the time of writing, I could not find any official announcement regarding when the iOS 27 SDK (Xcode 27) will become mandatory for App Store submissions. Based on Apple's historical policy and current publicly available information, is it reasonable to assume that applications built with Xcode 26 using the iOS 26 SDK will continue to be accepted by App Store Connect until at least March 2027? This information is important for determining whether we need to invest additional engineering effort to migrate an application that is scheduled to reach end of sale in March 2027.

Thank you, Claude31. The documentation you pointed me to was extremely helpful and appears to answer my original question regarding the planned removal of UIDesignRequiresCompatibility. For context, I am responsible for an enterprise VoIP application that is currently scheduled to reach end-of-sale on March 31, 2027. Migrating this application to fully support Liquid Glass would require substantially more work than simple font-size adjustments and would likely take approximately two months of development and testing effort. Because the application is approaching its planned end-of-sale date, we are trying to determine whether a full Liquid Glass migration is justified, or whether it would be reasonable to continue using UIDesignRequiresCompatibility until the product reaches end of life. Because of that, I would like to better understand the exact meaning of the following statement: "The system ignores this key when you build for iOS 27 or later..." Could someone clarify the following points? What exactly does "build for iOS 27 or later" mean in this context? Building with the iOS 27 SDK? Setting the deployment target to iOS 27? Or simply running the application on iOS 27 devices? If an application is built using Xcode 26 and the iOS 26 SDK, will UIDesignRequiresCompatibility continue to function when that application runs on iOS 27? Understanding this distinction is important for our migration planning and end-of-life strategy. Thank you.

Thank you for sharing your experience with Liquid Glass. I understand the UI issues you described, and they are certainly important for developers planning migration work. However, my primary question is not about the migration effort itself, but about Apple's current plan for UIDesignRequiresCompatibility. Specifically, I would like clarification from Apple on whether the statement "We intend this option(UIDesignRequiresCompatibility)to be removed in the next major release." still reflects Apple's current plan, and whether "the next major release" should be interpreted as iOS 27. This information is important for planning the migration schedule of our application.

@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?