Thank you very much for your detailed response and valuable recommendations.
At this stage, our application is still built using Xcode 26 and the iOS 26 SDK. Our primary priority right now is to validate runtime behavior for our existing binary running on iPhone Duo. We fully understand that full‑featured support for iPhone Duo requires Xcode 27 plus Scene lifecycle adoption, and we plan to implement those adaptations incrementally in future releases.
What we want to clarify specifically: aside from the expected black bars introduced by system compatibility mode, do our existing patterns raise functional bugs or layout risks on iPhone Duo when built with Xcode 26? The legacy patterns we are concerned about are:
Window creation via init(frame:), where frame is derived from UIScreen.main.bounds, without adopting SceneDelegate lifecycle. Manual non‑AutoLayout layouts that read UIScreen.main.bounds directly to obtain view width. Whether viewWillTransitionToSize:withTransitionCoordinator: will still fire on fold/unfold state changes under this Xcode‑26‑built compatibility mode. We would like to distinguish which of these usages must be fixed even for our Xcode‑26‑built release, versus which ones are safely handled by system compatibility and can remain unchanged for the time being. We are trying to decide whether urgent compatibility patches are required for our current Xcode 26 build.
Thank you again for your support.
Because your application is built against the iOS 26 SDK, it will be put into a compatibility mode that simulates behavior more similar to previously released iPhones when running on Duo. It will be ignorant of many of the behaviors unique to iPhone Duo, but should still behave in a way that is reasonable to your end user.
