Under macOS 27 using Mac Catalyst for a UIKit-based app, If you present a view controller with a table view as a form sheet or page sheet, row reordering fails to function. You can drag a row as expected but the blue movement bar never appears and if you drop the row it simply returns to its original location. The exact same view controller presented as a popover works just fine. The exact same view controller not presented as a modal (such as the app's root controller) works just fine. This is a serious bug affecting existing applications and being reported by paying customers. This has been reported as FB25038883 which includes a simple sample app demonstrating the issue.

As reported in FB25363417: A UIKit based app running on macOS 27.2 (or macOS 27.0.1) via Mac Catalyst no longer has functioning state restoration. Upon app restart, there is no NSUserActivity being provided to the scene in the UISceneDelegate method scene(_:willConnectTo:options:). This can be tested with Apple’s own sample app “Restoring your app’s state”. Just update the sample project with support for a Mac Catalyst build. Using Xcode 27.2 on a Mac with macOS 27.0 or 27.2, build and run the Mac Catalyst version of the app. The main screen appears with a list of products. Select any product so you see details of the product. Quit the app. Run the app again. Note that you are not returned to the previously selected product detail screen. Instead, you just see the main list of products. If you run the same app and perform the same steps on a Mac running macOS 26.x, then when the app is restarted, you correctly get returned to the previously selected product detail screen. The problem is being caused by no NSUserActivity being passed into the scene delegate on app startup. While running the app on a Mac with macOS 27.x, put a breakpoint on the initial guard statement in scene(_:willConnectTo:options:) and you will see there is no activity on app restart. This is impacting paid customers of my existing app since upgrading to macOS 27. They no longer get returned to the app’s previous state when restarting the app. It is expected that state restoration should work on macOS 27 just as well as it does under macOS 26 in an app built with Mac Catalyst.

During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. 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 for your support.

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.

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

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.

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!

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?

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

On iPhone Duo (iOS 27.1), when UIKit moves a navigation controller's system back button into the vertical bar, the button always shows the system chevron. Every public API for customizing the back indicator image is ignored there, although the same configuration is honored in the horizontal (top) navigation bar. APIs tested (each one alone, on the second view controller of a UINavigationController stack, with no leftBarButtonItem): A. Nothing set (default). B. UINavigationBar.standardAppearance set to a UINavigationBarAppearance on which setBackIndicatorImage(_:transitionMaskImage:) was called. C. Same appearance assigned to all four UINavigationBar properties: standardAppearance, compactAppearance, scrollEdgeAppearance, compactScrollEdgeAppearance. D. Same appearance assigned to all four UINavigationItem properties of the pushed view controller: standardAppearance, compactAppearance, scrollEdgeAppearance, compactScrollEdgeAppearance. E. Legacy UINavigationBar.backIndicatorImage and UINavigationBar.backIndicatorTransitionMaskImage, with no appearance objects set. F. UINavigationBar.appearance() proxy: all four appearance properties, set before the navigation controller is created. G. UINavigationItem.backBarButtonItem of the previous view controller set to UIBarButtonItem(image:style:target:action:). H. Control: UINavigationItem.leftBarButtonItem set to UIBarButtonItem(image:style:target:action:) with the same image (axisBehavior left at .automatic). The marker image is UIImage(systemName: "arrow.uturn.backward"), so it cannot be mistaken for the system chevron. Results: Top navigation bar (iPhone 17 Pro iOS 27.0, and iPhone Duo open with portrait UI): B, C, D, E and F show the custom image. G shows the chevron followed by the image. Vertical bar (iPhone Duo closed; iPhone Duo open with landscape UI; also inside a UITabBarController with the tab bar hidden or visible): A through G all show the system chevron. Only H shows the custom image. At viewDidAppear, the app confirms that the configuration is in place: navigationBar.standardAppearance.backIndicatorImage is the marker image (B, C), navigationItem.standardAppearance is non-nil (D), and traitCollection.verticalBarEdge is .trailing. This contradicts the guidance given by an Apple Technology Evangelist in https://developer.apple.com/forums/thread/847875: "If you are only replacing the icon on the back button, you could use set the backIndicatorImage and maintain default system behavior. This would be the recommended approach." As things stand, the only way to show a custom back icon in the vertical bar is to replace the system back button with a leading item. That loses the system behavior that comes with it: UINavigationController.interactivePopGestureRecognizer, interactiveContentPopGestureRecognizer and the back-history menu.

Hi, I've discovered that my Keyboard Extension is unable to detect any hinge status update on iPhone Duo. I tired both UIKit and SwiftUI approach - nothing works. Is there any workaround to make it work? Reproducible demo: https://www.icloud.com/iclouddrive/0460exMJtAdRkpk8EDjb751nw Xcode 27.1 (27A9269) iOS 27.1 beta 1 (24A94401) I also created a bug report: FB24883137

Hi, it seems there's an issue with back button on iOS 27 when it has a custom title defined and the title is forced to collapse in runtime due to other items taking space in the header. I have the following setup in the header of the second screen in a stack: a back button that displays custom title and 2 rightBarButtonItems. There is a toggle that adds the third item to rightBarButtonItems or removes it. This forces to hide the back title or display it again. I expect the button to resize as needed and go back to previous state as needed, without flashing, and correctly respond to presses at all times. What actually happens: I repeat the action multiple times (up to 5 times should be enough), the back button goes blank and unresponsive. There is only the glass background present, which does correctly resize. I filed the issue in Feedback Assistant: ID FB24801640 Is there a way to workaround this?

Let's say we start with a fully open iPhone Duo. We then present a view controller as a form sheet or page sheet. If the device is then rotated between landscape and portrait, the view controller's viewWillTransition(to:with:) is called to reflect the change in size between orientations. So far so good. Now put the fully open Duo in landscape. Then partially close the Duo. The presented view controller will automatically move off to the left half of the screen to avoid the fold. That's expected. However, the view controller's viewWillTransition(to:with:) is NOT called in this case even though its size has changed. Does this seem like a bug or is this somehow expected? I have a particular view controller that needs to know its size has changed so it can make some adjustments. Other lifecycle methods such as viewDidLayoutSubviews are called but I'd prefer to have viewWillTransition(to:with:) called.

I've looked at the UIKit docs for UIView reservedRegions(kind:options:). I've watched the video "Strike a pose with adaptive layouts on iPhone Duo". So I know how to get the current reserved regions. But I can't find the APIs to know when the reserved regions change. This means I can setup my custom view controller with the reserved regions that exist when the view controller is first displayed. But if the user changes the Duo, say from fully open to partially open, what API is triggered that lets me know that I need to call reservedRegions(kind:options:) and update the layout as needed? I played around with UIHingeInteraction but that isn't the right approach. In most cases I tried calling reservedRegions(kind:options:) on each call to the interaction handler but I almost always got the wrong results (maybe a simulator issue?). And of course that interactiion handler will be called a lot just to report the new fold angle. I also tried various UIViewController methods for size changes and registered for size class changes. None of these were appropriate. I just need a single notification that the Duo went from fully open to partially open, partially open to fully open, and partially open between landscape/portrait so that I can call reservedRegions(kind:options:) and get the correct, current divider info. What am I missing? My use case is for a custom fullscreen view controller that needs to layout a few items based on whether the Duo is fully open or partially open and whether the fold is horizontal or vertical. Unless I'm mistaken this precludes the use of UIArrangementViewController since I only have one view controller with one set of content to display. Showing the view controller as a form sheet, page sheet, or popover won't work since I need this to be fullscreen. I just need the fullscreen content to adjust for any fold (reserved region).

Hi apple team, we have a requirement where on certain pages, tabbar should not be displayed. it worked on non iphone-duo phones by utilizing tabbar.isHidden = true yet on iphone duo, it didnt work. is it a bug or are there a missing api that i didnt impl? thanks

Since iPadOS 26 we have been seeing a crash inside the system keyboard. It happens while the system keyboard renders key images. Our code is not on the crashing stack. Crash The app is terminated by an uncaught NSInvalidArgumentException. The NSXPC encoder fails to allocate a very large buffer while a keyboard image cache item is being encoded: NSInvalidArgumentException: *** NSAllocateMemoryPages(60003072) failedRequested sizes seen across reports: 60,003,072 / 60,558,656 / 78,724,160 / 240,001,920 / 933,149,952 bytes. Xcode Organizer groups these reports under the signature TextInput: -[TIImageCacheItem encodeWithCoder:] + 276. Relevant frames (main thread, simplified): objc_exception_throw NSAllocateMemoryPages NSXPCEncoder (encoding) -[TIImageCacheItem encodeWithCoder:] + 276 (TextInput) TIDispatchSync TIImageCacheClient UIKeyboardCache -[UIKBKeyView displayLayer:] ... UIApplicationMainScope (about 3 months of data) 327 crashes from 43 users. iPad only. iPadOS 26.1 – 26.7.1. No crashes on iPhone and none on iPadOS 18 or earlier. No single iPadOS 26 minor version stands out. The first occurrence did not line up with any release of our app. Our keyboard-related code did not change at that time. Free memory at crash time ranges from 33 MB to 4.8 GB. Some crashes happen within 40 seconds of launch. This looks like an abnormally large encode request, not memory pressure or a leak in the app. All affected users use the zh_CN locale. Context The screen has a plain UITextField, the standard system keyboard, and no custom inputView. It also has a UIIndirectScribbleInteraction for Apple Pencil handwriting. The crash happens shortly after the keyboard appears. Breadcrumbs show UICompatibilityInputViewController, UISystemInputAssistantViewController and UIPredictionViewController being set up just before the crash. Many crashes happen when the app window is not full screen (Split View / Stage Manager). For example, a 629.5 pt wide app window on a 1180 pt screen, or 936×954 on 1373×954. Some devices were rotating frequently. In a few cases there was a rapid burst of multi-tap gestures about 20 ms apart just before the crash (Pencil/Scribble-like input). What we tried We could not reproduce it on our own iPads running iPadOS 26. Memory stays flat and there is no crash. Questions Is this a known issue in the iPadOS 26 keyboard image cache (TIImageCacheItem)? Is there a recommended workaround on the app side, for example avoiding certain input view reloads or trait changes while the keyboard is visible?

The following has been reported as FB25281446 I've come across a serious user interface issue on the iPhone Duo when you show a popover with the permitted arrow direction set to only left or right. Here's a screenshot from a test app of a correct popover shown from a form sheet on a fully open iPhone Duo: Here's the same UI after switching the Duo from fully open to partially open: Note how the popover is now partially offscreen. Oddly the toolbar is still kept onscreen. You are unable to scroll to the last rows of the table view. You can replicate this problem by taking the following steps: 1) Create a new Storyboard/Swift app with Xcode 27.2 RC 2) Edit the Main storyboard by removing the default view controller 3) Add a navigation controller (and its default root view controller) 4) Set the navigation controller as the initial view controller 5) Replace the contents of the default ViewController.swift file with the following code: ```swift import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let showPopover = UIBarButtonItem() // Show the view controller as a popover let action = UIAction(title: "Popover", handler: { _ in let vc = ViewController() let nc = UINavigationController(rootViewController: vc) nc.modalPresentationStyle = .popover nc.popoverPresentationController?.sourceItem = showPopover nc.popoverPresentationController?.permittedArrowDirections = .any self.present(nc, animated: true) }) showPopover.primaryAction = action self.navigationItem.rightBarButtonItem = showPopover // Show the view controller in a form sheet let showFormSheet = UIBarButtonItem() let action2 = UIAction(title: "FormSheet", handler: { _ in let vc = ViewController() // Applying a preferred content size affects the results in one // case - the popover works correctly when the Duo is fully open // in portrait and you show a popover from a form sheet. //vc.preferredContentSize = .init(width: 540, height: 620) let nc = UINavigationController(rootViewController: vc) nc.modalPresentationStyle = .formSheet self.present(nc, animated: true) }) showFormSheet.primaryAction = action2 self.navigationItem.leftBarButtonItem = showFormSheet // Show some dummy toolbar items to help demonstrate the issue self.navigationController?.isToolbarHidden = false self.toolbarItems = [ UIBarButtonItem(systemItem: .add), UIBarButtonItem.flexibleSpace(), UIBarButtonItem(systemItem: .action), ] } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { return 1 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return 20 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .subtitle, reuseIdentifier: "cell") cell.textLabel?.text = "Row \(indexPath.row)" cell.detailTextLabel?.text = "Tap me to show popover" return cell } // Show a popover from a selected cell. The popover will appear partially // offscreen under the following conditions: // - When the Duo is fully open and landscape: // - A row near the bottom of the root view controller is selected. // - When the Duo is fully open and portrait: // - A row near the bottom of the root view controller is selected. // - A row near the bottom of a form sheet is selected (unless the form // sheet has a preferredContentSize set). // - When the Duo is partially open and landscape or portrait: // - A row near the bottom of the root view controller is selected. // - A row near the bottom of a form sheet is selected. // - If you then fully open the Duo, the partially offscreen popover // moves into the correct, fully visible position. // Note that the toolbar of the partially offscreen popover stays on screen. // // There are no issues when the Duo is closed. override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) { if let cell = tableView.cellForRow(at: indexPath) { let vc = ViewController() let nc = UINavigationController(rootViewController: vc) nc.modalPresentationStyle = .popover nc.popoverPresentationController?.sourceItem = cell // The problem only happens if the arrow is limited to left or right nc.popoverPresentationController?.permittedArrowDirections = [ .left, .right ] self.present(nc, animated: true) } } } ``` 6) In the Main storyboard, change the root view controller's class to ViewController 7) Build and run the app against an iPhone Duo running iOS 27.2 RC You can now replicate the two screenshots by fully opening the Duo and putting it in landscape. Then do the following: 1) Tap the FormSheet button 2) In the form sheet table, select a row near the bottom of the form sheet 3) Note the popover appears correctly with an arrow on the right side pointing to the selected row 4) Now put the iPhone Duo in the partially open mode (still landscape) 5) Note the problem. The popover moves partially offscreen. You can’t even scroll to the last row. The popover show remain fully onscreen and of reasonable height just like it was when the Duo was fully open. As noted in the ViewController.swift file, the issue appears under the following conditions: - When the Duo is fully open and landscape: - A row near the bottom of the root view controller is selected. - When the Duo is fully open and portrait: - A row near the bottom of the root view controller is selected. - A row near the bottom of a presented form sheet is selected (unless the form sheet has a preferredContentSize set). - When the Duo is partially open and landscape or portrait: - A row near the bottom of the root view controller is selected. - A row near the bottom of a presented form sheet is selected. - If you then fully open the Duo, the partially offscreen popover moves into the correct, fully visible position.

On the iPhone Duo, default toolbar items are 48 pt instead of 44 pt, even when the navigation bar is horizontal. There doesn't seem to be a public API to query this size, making it difficult to match custom toolbar items to system controls without device-specific checks. I've filed FB25271102 requesting an API to expose the default toolbar item dimensions, ideally through a SwiftUI environment value.