For a full-screen game with a Metal/Unreal rendering view and a SwiftUI overlay for touch controls, what is the recommended way to keep interactive controls away from the hinge while still allowing the rendered game world to use the full display? Would you recommend querying ReservedRegion in the SwiftUI overlay while allowing the underlying render view to remain edge-to-edge? Also, should control placement respond continuously while the device is being folded, or primarily respond to layout/reserved-region changes once the pose changes?

We've been reverse-engineering behavior from the Simulator device profile alone. Is there a WWDC session, updated UIKit/SwiftUI documentation, or sample project specifically covering foldable iPhone adoption (window/scene handling, size-class behavior, collection/table view sizing, and the fold-posture API surface) that we should be building against instead of inferring behavior empirically?

During a fold, UIScreen.main.bounds stays at the outer-display size while window.windowScene?.screen.bounds updates. Layout that still reads UIScreen.main (sheet heights, map padding, title widths) is wrong on the inner display. Should apps stop using UIScreen.main entirely and always read the window scene’s screen?

Problem: iPhone Duo supports multiple windows using Split Views. However, we cannot programmatically close windows using requestSceneSessionDestruction because we get the following error: "This functionality is not supported for this device idiom." This seems like a miss in Apple's requestSceneSessionDestruction implementation. If the Duo is going to let users open multiple windows (where supportsMultipleScenes is true for the Duo), then developers should be able to close them via requestSceneSessionDestruction, too. 🤔 Is this a bug? I have filed a ticket here in case it is: FB25353479 Additional implementation details: Our app supports multiple windows on iPad devices. The Duo is the first phone to support multiple windows as well. For user convenience, our app has an option to combine information from all windows and then collapse everything down to one single window. We use requestSceneSessionDestruction to close the extraneous windows afterward. This works great on iPad, but we get the unsupported device idiom error on the Duo only. We have no way of closing windows programmatically as far as I can tell.

Since upgrading to macOS 27, I have encountered native menus becoming unresponsive. It is reproducible via a short sequence of mouse actions in Apple’s TextEdit application. The following linked zip contains a Python reproduction script and a shell launcher that prepares its dependencies: https://drive.google.com/uc?export=download\&id=1q9DtRC7zpnhK50v4VmvuRAf2sq6I9jaz Expected: The menu continues responding to mouse movement, clicks and Escape. Observed: The menu becomes unresponsive after the sequence. Could anyone confirm whether the attached reproduction triggers the issue on their system? Is this a known AppKit menu-tracking issue, and are there any suggested workarounds or additional diagnostics that would help investigate it? Thank you.

On iPad running iOS 26, UIKeyboardType.decimalPad sometimes appears as a floating keypad (compact panel) instead of the docked, full-width keyboard. Our app attaches a custom toolbar via inputAccessoryView, so the floating keypad hides the toolbar and breaks the flow. We’d like to opt out of the floating keypad or force the keyboard to remain docked when a toolbar is present. Environment Device: iPad (multiple models) OS: iPadOS 26.0 App type: UIKit Field: UITextField with keyboardType = .decimalPad We present a custom toolbar via inputAccessoryView Expected Docked (full-width) keyboard so the inputAccessoryView toolbar is visible and sized correctly. Actual A floating decimal keypad appears and covers content; our accessory toolbar isn’t visible/attached to it. Why this matters Our toolbar contains required domain actions (Done/Next, Previous). When the keypad floats, the user loses these controls. Questions Is there a supported way to opt out of the floating numeric keypad on iPad when using decimalPad? Is there an API/trait to prefer docked keyboard (e.g., when an inputAccessoryView is present)?

Hi everyone, I'm experiencing a significant difference in SwiftUI layout behavior between the iPhone Duo simulator and a physical iPhone Duo. I've already adjusted my layout to work correctly in the simulator, but the same app behaves differently on the actual device. 1. Folded Simulator: The tab bar is positioned on the right side, as expected for iPhone Duo. The view respects the right-side layout, and scroll views extend naturally behind the tab bar, behaving as expected. Physical device: The tab bar appears at the bottom, like a regular iPhone, instead of on the right. The view is also cropped on the right side. 2. Unfolded Simulator: The tab bar and navigation view both appear correctly. Physical device: The tab bar remains at the bottom, even in landscape orientation, instead of using the expected Duo layout. The main content also starts from the bottom of the navigation view, resulting in an incorrect layout. The most confusing part is that the layout works correctly in the simulator but not on the physical device. Has anyone encountered this behavior on a physical iPhone Duo? Could this be related to the iOS version, SDK version, SwiftUI's automatic tab bar adaptation, or a device-specific bug? I'd appreciate any insights, especially from developers who have tested their SwiftUI apps on actual iPhone Duo hardware. Environment: Xcode version: 27.1 iOS SDK: 27.1 Physical device iOS version: 27.2 Thanks!

During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. TL;DR Setting UITextContentType.cellularIMEI works on iOS 27 without any entitlement while not on prior verisons. is it expected behaviour? Test details Implementation: textContentType = .cellularIMEI on the IMEI input field Entitlement status: no carrier-related entitlements in the test build Observed results iOS 27: The IMEI AutoFill suggestion appears and works in any app, regardless of carrier entitlement. iOS 26 and earlier: The IMEI AutoFill suggestion does not appear. Questions Is it the expected and intended behavior that, on iOS 27, IMEI AutoFill is available to any app without a carrier entitlement? On iOS versions earlier than 27 (iOS 17.4 to 26), is the public cellular plan entitlement required for IMEI AutoFill to work? If not, are there other conditions or requirements? On dual-IMEI devices, which IMEI (IMEI or IMEI2) is filled when .cellularIMEI is used on iOS 27? Should we use .cellularIMEI1 / .cellularIMEI2 to specify it explicitly? Thank you in advance.

Description: The time scale values on the battery usage curve in macOS 27 are displayed incorrectly. The screenshot timestamp is 14:39:11, October 20. Under the "Last 24 Hours" tab for Battery Level and Screen On Time charts, the timeline shows usage extending past 21:00 on October 20. This timestamp does not match the actual current time. It appears the timeline axis failed to shift correctly as time progresses. For comparison: a reference screenshot captured on macOS 26 at 09:30, August 8. Its battery usage timeline rendered correctly. The bottom time span covered August 7 to August 8, which is the expected and proper display behavior. This bug only exists in macOS 27’s battery usage chart. The older macOS 26 implementation works correctly. Device: MacBook Air M5 macOS version: macOS 27.2 RC

If my NSDocument.canConcurrentlyReadDocuments(ofType:) implementation returns true, often when launching the app, an untitled document is created regardless whether another document is restored. If document reading is not concurrent, an untitled document is only created when no other document is restored, as expected. The issue happens on most app launches when a document is restored. If the restored document takes long to load (which can be simulated by putting sleep(1) in the Document.read(from:ofType:) implementation), the issue always happens. Is this expected, or is there a workaround? I created FB25340015.

Hi, My app (SmashTunes) can display a floating window with artwork of a music track that is displaying. It does for over a decade in multiple versions of macOS. I do this by calling window?.isMovableByWindowBackground = true. This stopped working under macOS 27. I've read some reports of others not being able to move windows. It should supposedly have been fixed in macOS 27.2, but it is not. Has anyone on this forum run into the same problem, or know of a different way to move windows around on the screen? When I add add a titlebar, I can drag it by the titlebar, but that is not really an option for my use case.

# iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices ## Description After upgrading a physical iPhone to iOS 27.2, my Ionic Angular application running on Cordova no longer renders correctly. The left and right black areas that were previously visible along the screen edges have disappeared, and the iOS status bar (time, network connectivity, and battery) is now visible in a way that affects the app's layout. Some UI components are consequently shifted from their expected positions. For example, some of the header components are pushed as the status bar starts to appear(status bar does not show on iOS 27.1 or lower) **The same app works correctly on iOS 27.1 on the same device.** The problem only appears after upgrading to iOS 27.2. Interestingly, I cannot reproduce the issue in the iOS simulator, even when running the same app on the iOS 27.2 simulator. So far, the issue appears to affect physical devices only. ## Expected behavior The app should retain its previous layout, including the black areas on the left and right edges(safe area view). The status bar and safe-area handling should remain consistent with the behavior on iOS 27.1, without unexpectedly shifting UI components. ## Actual behavior - The black areas on the left and right edges disappear. - The iOS status bar becomes visible and appears to affect the page layout. - Some UI components are shifted from their expected positions. - The issue occurs on a physical device running iOS 27.2 but cannot currently be reproduced in the simulator. ## Current configuration My `config.xml` contains: ```xml <preference name="StatusBarOverlaysWebView" value="false" /> ``` My viewport meta tag is: ```html <meta name="viewport" content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"> ``` I am using Ionic Angular with Cordova and an embedded iOS WebView. ## Steps to reproduce 1. Install and launch the app on a physical iPhone running iOS 27.1. 2. Observe that the layout and left/right black areas render as expected. 3. Upgrade the same device to iOS 27.2. 4. Launch the same app build. 5. Observe that the black areas disappear and the status bar/layout behavior changes. The issue has not been reproduced in the simulator. ## Questions 1. Has there been a change in iOS 27.2 affecting `WKWebView` safe-area insets, viewport sizing, or status-bar layout? 2. Could the native WebView frame or safe-area handling behave differently on physical devices compared with the simulator? 3. Is there a known workaround that does not require upgrading `cordova-ios`? 4. Is this more likely to be an iOS/WebKit regression or an incompatibility with the Cordova StatusBar plugin? I would appreciate any guidance on how to diagnose or work around this issue. I can provide screenshots from iOS 27.1 and 27.2, as well as additional diagnostics, if helpful. ## Environment - Framework: Ionic Angular - Platform: Cordova iOS - Affected OS: iOS 27.2 - Previously working OS: iOS 27.1 - Device: iPhone (physical device; exact model to be provided) - Simulator: Issue not reproducible - `StatusBarOverlaysWebView`: `false` - Viewport: `viewport-fit=cover`

Hi, I would like to share an issue with the bottom accessory on iPhone Duo (iOS 27.1 beta 1). When the device is rotated from landscape to portrait and back to landscape, the bottom accessory shrinks and is no longer centered between the edge of the screen and the vertical tab bar. Steps to reproduce: Create UITabBarController with a regular UIView set as bottom accessory Open the app on iPhone Duo in unfolded landscape orientation Rotate the device to portrait and back to landscape The bottom accessory is smaller than prior to the orientation changes and isn’t centered between the edge of the device and the vertical tab bar anymore Set the accessory to nil and back to restore initial width Expected: Bottom accessory keeps its width across orientation changes Actual: Width of the bottom accessory changes after orientation changes (landscape -> portrait -> landscape). I’m using Xcode 27.1 beta and iOS 27.1 beta SDK (24A94403). I submitted a report via Feedback Assistant, here is the report ID: FB25002243. In the report I attached a minimal reproduction example and a video recording of the bug. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = TabBarControllerWithAccessory() window.makeKeyAndVisible() self.window = window } } // TabBarControllerWithAccessory.swift import UIKit class TabBarControllerWithAccessory: UITabBarController { override func viewDidLoad() { super.viewDidLoad() tabs = [ UITab(title: "First", image: UIImage(systemName: "1.circle"), identifier: "first") { _ in ScreenViewController() }, UITab(title: "Second", image: UIImage(systemName: "2.circle"), identifier: "second") { _ in ScreenViewController() }, ] bottomAccessory = UITabAccessory(contentView: AccessoryContentView()) } } class ScreenViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground let mountButton = UIButton(configuration: .filled(), primaryAction: UIAction(title: "Mount") { [weak self] _ in self?.tabBarController?.bottomAccessory = UITabAccessory(contentView: AccessoryContentView()) }) let unmountButton = UIButton(configuration: .filled(), primaryAction: UIAction(title: "Unmount") { [weak self] _ in self?.tabBarController?.bottomAccessory = nil }) let stackView = UIStackView(arrangedSubviews: [mountButton, unmountButton]) stackView.axis = .vertical stackView.spacing = 16 stackView.translatesAutoresizingMaskIntoConstraints = false view.addSubview(stackView) NSLayoutConstraint.activate([ stackView.centerXAnchor.constraint(equalTo: view.centerXAnchor), stackView.centerYAnchor.constraint(equalTo: view.centerYAnchor), ]) } } class AccessoryContentView: UIView { private let widthLabel = UILabel() override init(frame: CGRect) { super.init(frame: frame) backgroundColor = .systemOrange widthLabel.translatesAutoresizingMaskIntoConstraints = false addSubview(widthLabel) NSLayoutConstraint.activate([ widthLabel.centerXAnchor.constraint(equalTo: centerXAnchor), widthLabel.centerYAnchor.constraint(equalTo: centerYAnchor), ]) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func layoutSubviews() { super.layoutSubviews() let text = "\(bounds.width)" if widthLabel.text != text { widthLabel.text = text } } } Before: After: Thank you in advance!

Two things I've seen using the iPhone Duo simulator. I'm updating a venerable Objective-C app that dates back to iOS 4, but has been updated to be perfectly functional and appearance-appropriate on iOS 26. I'm building using the 21.1 beta SDK in Xcode 27.1 beta. TL;DR version: (1) my toolbar items vanish in vertical mode except while being tapped or dragged; and (2) the nav bar has an opaque, fixed background even as its title scrolls with underlying content. Has anyone else seen these oddities, and any ideas as to how I can fix 'em? First, with the Duo opened and taller than wide, the nav and tab bars in my app appear horizontally, as I would expect them to. But in any other pose or orientation, the bars adopt a vertical display, and aside from the left edge, their items are invisible: When I tap or drag on them, they become visible: When I stop tapping or dragging, they vanish again. Why do the vertical items go invisible, and how can I keep 'em always visible? Second, my scrolling view lies under the nav bar (in z-order) but extends to the top of the screen. If I scroll the view, it moves up onscreen, behind the opaque nav bar, although the nav bar's title scrolls up, too: If I go "far enough", the title scrolls off completely and the view's contents are visible full-height, but with the nav bar's background remaining. If I don't scroll that far, the title reappears when I stop, and the area above the nav bar goes opaque white, too, covering the content: Is it possible to disable the scrolling behavior on the nav bar title? (I'll just position my scrolling view to start below it spatially.) Alternatively, how can I turn off the background opacity? I've tried setting the background to clearColor and opacity to false... nav.navigationBar.backgroundColor = [UIColor clearColor]; nav.navigationBar.opaque = false; ...but these had no effect. Help me Obi-Wan Kenobi, you're my only hope...

Hi, I would like to share an issue with UITabBarController's vertical tab bar and iPhone Duo's unfolded pose. On iPhone Duo (27.2 beta 3), when tab bar controller is added to the view controller while in unfolded pose, the vertical tab bar doesn't appear unless the tab bar controller view's frame is set manually before adding it to the parent's view. Show any VC. Use unfolded Duo pose. After some time/on button press add a UITabBarController to it: (https://developer.apple.com/documentation/uikit/creating-a-custom-container-view-controller#Add-a-child-view-controller-programmatically-to-your-content) with Auto Layout constraints. Vertical tab bar does not appear. Fold and unfold the device. The tab bar appears. Expected: Tab bar appears after adding the UITabBarController in unfolded Duo pose. Actual: Tab bar does not appear after adding the UITabBarController in unfolded Duo pose. In Feedback Assistant report (FB25261013) I attached minimal reproduction example and recordings showing the different behavior in folded and unfolded poses and behavior with manual frame application fix (commented out in minimal reproduction example). Minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } window = UIWindow(windowScene: windowScene) window?.rootViewController = ViewController() window?.makeKeyAndVisible() } } // ViewController.swift import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground let button = UIButton(configuration: .filled(), primaryAction: UIAction(title: "Show Tab Bar Controller") { [weak self] _ in self?.showTabBarController() }) button.translatesAutoresizingMaskIntoConstraints = false view.addSubview(button) NSLayoutConstraint.activate([ button.centerXAnchor.constraint(equalTo: view.centerXAnchor), button.centerYAnchor.constraint(equalTo: view.centerYAnchor), ]) } private func showTabBarController() { let tabBarController = UITabBarController() tabBarController.tabs = ["First", "Second", "Third"].map { title in UITab(title: title, image: UIImage(systemName: "circle"), identifier: title) { _ in let viewController = UIViewController() viewController.view.backgroundColor = .systemBackground return viewController } } addChild(tabBarController) // Uncomment to show the tab bar on the unfolded iPhone Duo. tabBarController.view.frame = view.bounds view.addSubview(tabBarController.view) tabBarController.view.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ tabBarController.view.topAnchor.constraint(equalTo: view.topAnchor), tabBarController.view.bottomAnchor.constraint(equalTo: view.bottomAnchor), tabBarController.view.leadingAnchor.constraint(equalTo: view.leadingAnchor), tabBarController.view.trailingAnchor.constraint(equalTo: view.trailingAnchor), ]) tabBarController.didMove(toParent: self) } } Thank you in advance.

What's the best practices to adopt iPhone Duo for a production UIKit app? What few things we need to consider during the development? "As long as we use auto layout, it should be fine" is this correct term for iPhone Duo? Meaning, as long as our app use proper auto layout, our app should be able to support iPhone Duo properly.

I have an App where I use the UISheetPresentationController to present a menu as a "drawer" (like the "FindMy" or "Maps") App. Because the sheet is presented over a map, I made the sheet semi-transparent/blurry, so the Map shines through, which looks nice. The sheet is using a UITableView with the "insetGroup" style, so the table cells have the nice rounded borders and there are margins to the sheet borders. When running the App on the iPhone Duo (Simulator) on the outer display, the tableView does no longer respect the "insetGroup" style, it is rendered like it would have the "plain" style, which destroys everything that look good. No rounded borders, no margins. However if I opt-out of the automatic "vertical toolbar behavior" (overriding preferredVerticalBarBehavior so it returns "disabled"), then everything looks great again, however then the sheet content might overlap with the sidebar icons and camera because it now covers the whole area up to the right screen border. Is this supposed to be this way (if yes, why?), is there a way to fix this, or do we have to wait for a bugfix within iOS 27.1? The tableview still claims to have the "insetGrouped" style, just it does not render this way. I did not see any similar issues under other circumstances. Only UISheetPresentationController seems to be affected by this. Is there a way to correctly detect if the App is running on an iPhone Duo, so we could use this detection to add workarounds for such issues?

Will the App Store surface apps that are optimised for iPhone Duo, for example a badge, a filter or editorial placement? And is "optimised" decided just by building against 27.1, or by something else? Will App Store Connect require dedicated iPhone Duo screenshots for the outer and inner displays?

Summary: With all Multitasking Gestures disabled and Full Screen Apps enabled, four/five-finger pinch or swipe gestures are still intercepted by the system and swallow all touch points, so the foreground app stops receiving touch input. This is most noticeable in games that rely on multi-finger controls. The issue has persisted from iPadOS 26.0 RC through 27.2 — over a year — and remains unfixed(open). Multiple Feedback reports have been marked Open without a fix. one related report was marked “Potential Fix Identified – For a Future OS Update” and later reverted. Environment: iPad running any iPadOS version from 26.0 RC through 27.2 Settings > Multitasking & Gestures > all gestures disabled Full Screen Apps enabled (not Stage Manager or windowed apps) Steps to Reproduce: On the above configuration, open any app (most noticeable in games). Perform a four-finger pinch, or a four/five-finger left/right swipe. Observe that all touch points are immediately swallowed by the system, and the foreground app stops receiving touch input. Expected Result: Since all multitasking gestures are disabled in Settings, four/five-finger gestures should not respond at all, and the app should continue receiving touch input normally. Actual Result: The system still intercepts touches in the gesture area, causing the app to lose touch input temporarily or persistently. In games that rely on multi-finger input, this effectively breaks controls. FB Number: FB24795986

If we have create a custom Navigation back item, while running on iPhone Duo simulator, we see it at normal position i.e. on screen's top left side. How can we move it to the safe area like when we use default back button?