Hi everyone, We are validating our existing legacy UIKit application on iPhone Duo, built using Xcode26 and the iOS26 SDK. Our app follows the classic AppDelegate‑only pattern. We do not adopt UIApplicationSceneManifest or SceneDelegate, so it runs under the system’s legacy compatibility container window. The codebase still heavily uses UIScreen.main, and we have not yet adopted UIWindowScene. Full scene‑based migration is planned for Xcode27, but we need to ship builds with Xcode26 for now and expect reasonable compatibility on iPhone Duo hardware. Most of our application UI displays correctly inside this system‑provided compatibility window. However we noticed a critical positioning defect for system‑owned permission alerts. System‑rendered authorization dialogs (push notification permission, photo library access, location permission — these are drawn by the system process, not our app) are positioned relative to the full physical inner display of iPhone Duo. Instead of centering within our app’s compatibility‑mode container viewport, these permission pop‑ups appear offset and misaligned against our app’s visible window bounds. I have three key questions: Is this mis‑positioning of system permission alerts expected documented behavior for non‑Scene, AppDelegate‑only legacy apps running inside compatibility mode on iPhone Duo when built with Xcode26 SDK? While we remain on Xcode26 SDK, before completing full scene‑based lifecycle migration for Xcode27: are there any known workarounds to correct or mitigate this system permission alert offset issue? Or is this a hard limitation of the legacy compatibility mode in Xcode26, meaning we cannot fix it until we fully migrate to scene‑based app lifecycle? If this is intended limitation, could anyone point me to official Apple documentation that covers this exact behavior for legacy apps on iPhone Duo? Thanks for any insight.

Hi, We are testing our legacy UIKit app on iPhone Duo, built with Xcode26 / iOS26 SDK. Important background: Our app is pure AppDelegate‑only, we do NOT adopt UIApplicationSceneManifest / SceneDelegate, runs in legacy compatibility mode. Codebase heavily uses UIScreen.main everywhere, no UIWindowScene adoption yet. We are in progress to adopt full iPhone Duo compatibility with Xcode27. For now, we need to ship builds using Xcode26 SDK and expect reasonable compatibility on iPhone Duo hardware. The system already provides legacy compatibility container window for our app. Most of our app UI renders correctly inside the system compatibility window on iPhone Duo. Problems we observed under Xcode26 build on iPhone Duo: System‑rendered permission alerts (push‑notification permission, photo library, location authorization dialog, drawn by system process) are centered relative to the full physical inner display, NOT centered inside our app’s compatibility‑mode window. The alert position is mis‑aligned with our app viewport. The system UINavigationBar layout offset issue: When running inside legacy compatibility window, system‑provided UINavigationBar calculates its top position against full physical screen safe‑area instead of the app compatibility container’s safe‑area. As a result, navigation bar appears too close to the top edge, mis‑aligned with the actual status‑bar area inside our app window. My questions: Are above two issues (system permission alert mis‑position, UINavigationBar safe‑area offset) the expected defined behavior for legacy non‑Scene apps running in compatibility mode on iPhone Duo when built with Xcode26 SDK? When staying on Xcode26 SDK (before we complete Xcode27 & scene‑based lifecycle migration): Is there any workaround we can apply to mitigate these two issues? Or are these limitations unavoidable under Xcode26 / legacy compatibility mode and we can only accept current behavior until we fully migrate to scene‑based lifecycle? 3. If these are expected limitations: is there any official documentation that explicitly describes these behaviours for legacy apps on iPhone Duo? Thank you.

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.

Background We are currently building our app with Xcode 26 and the iOS 26 SDK. We want to verify the runtime behavior on iPhone Duo. We have three questions: We haven't adopted SceneDelegate lifecycle management yet. We create the window using init(frame:), with the frame value taken from UIScreen.main.bounds. Will this implementation cause any issues on iPhone Duo? For all non-Auto Layout layouts, we fetch view width by reading UIScreen.main.bounds. Do we need to rewrite all these code points? Will this lead to layout exceptions when the device switches between folded and unfolded states? We observed the system handles fold/unfold compatibility, but black bars appear in both states. Can our app keep consistent view dimensions in both modes? Will viewWillTransitionToSize:withTransitionCoordinator: fire to trigger re-layout when switching between folded and unfolded states?