I'm creating a custom keyboard by subclassing UIInputView. This is set as a text field's inputView property. This is a simple keypad similar to the standard numeric keypad keyboard. In fact, my UI lets the user switch between the standard numeric keypad and my custom input view. Given this it would be very nice if my custom input view was the same height as the standard keypad. If there a proper way to subclass UIInputView such that its height is the same "standard" height as the numeric keypad when run on any iOS device from iOS 17 through 27.3? I do not want to have to hardcode dozens of heights for every model iPhone and iPad, not to mention the 5 different heights you get on the iPhone Duo. I've tried various combinations of setting allowsSelfSizing to true and false along with returning a height of UIView.noIntrinsicMetric in intrinsicContentSize as well as not setting intrinsicContentSize at all. The closest result is when allowsSelfSizing is set to false. In that case my custom input view's height is somewhat similar to the standard keypad but in some cases it's off by 20-30 points roughly. Has anyone implemented a custom UIInputView that gets the standard keyboard height without hardcoding device specific heights?

Using Xcode 27.1 RC, the iPhone Duo simulator (Device Hub) only comes with the Settings and Safari apps. Am I missing something? Are there plans to have the usual simulator apps such as Photos, Calendar, Reminders, Maps, etc.? In these early stages it would be really nice to have some real apps to look at for examples of how some things should work/appear on the Duo in different layouts.

Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.

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.

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

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.

I purged my DerivedData folder then did a clean build of my app using Xcode 27.2 RC. I then submitted my build through the Organizer window. I then logged into App Store Connect. When I try to submit the build for external testing, App Store Connect is giving me an error that beta tools can't be used. I'm not using beta tools. I'm using release candidate tools. Less important but I thought beta tools could be used for testing. Anyway, is this an AppStore Connect issue or am I doing something wrong?

I have Xcode 27.1. When I open the Developer Documentation window, it only has the 27.0 APIs. While running Xcode 27.1 if I go to Xcode -> Settings -> Components -> Developer Documentation -> Info, the info window shows the Xcode version as 27.0 and the Developer Documentation Version as 10M13950. Xcode -> About Xcode definitely shows version 27.1. It's very difficult trying to work on iPhone Duo support when the developer documentation doesn't show any of the iOS 27.1 APIs. Is there any way to get the proper documentation loaded?

If you run Safari in the iPhone Duo simulator and choose to share something you get a screen similar to the following: In my own app, if I present a UIActivityViewController I get a similar result. Note that the share sheet does not cover the vertical toolbar at all. So my question is how to present a UISheetPresentationController to look the same way. In other words, how to get the width of the UISheetPresentationController to take into account the vertical toolbar? All of my existing code to create and present a UISheetPresentationController result in the UISheetPresentationController taking the full width of the screen. The contents of the sheet take the safe area into account, but that's not the same result. I need the sheet itself to be narrower. I don't see an API for this. Or does this require more complicated presentation controller / delegate setup? Here is some relevant code in the view controller that I want displayed in the sheet: self.modalPresentationStyle = .popover self.presentationController?.delegate = self if let sheet = popoverPresentationController?.adaptiveSheetPresentationController { popoverPresentationController?.passthroughViews = [] sheet.detents = [ .medium(), .large() ] sheet.largestUndimmedDetentIdentifier = nil sheet.prefersGrabberVisible = false sheet.prefersScrollingExpandsWhenScrolledToEdge = true sheet.prefersEdgeAttachedInCompactHeight = true sheet.widthFollowsPreferredContentSizeWhenEdgeAttached = true } Or maybe UISheetPresentationController is the wrong approach.

When creating a UIBarButtonItem using the standard UIBarButtonSystemItem values of UIBarButtonSystemItemSave or UIBarButtonSystemEdit you end up with text-only buttons. The text-only buttons are an issue with the iPhone Duo since such buttons do not get put in the vertical sidebar. This is a problem with a view controller with scrollable content. The text-only Save or Edit buttons can scroll out of view leaving the user confused about how to complete their work on the screen. Related is the UIViewController editButtonItem which gives the standard Edit/Done toggle button. Since the button shows the text "Edit" the button doesn't get put in the vertical sidebar. This is despite the Done display being shown as a checkmark icon.

Before I file a bug report I wanted to verify that I'm not missing something. If I setup a view controller in a navigation controller and I add a view with a constraint that lines it up with the view controller's view's layoutMarginsGuide (leadingAnchor or trailingAnchor), in several cases the view will not line up with buttons added in the navigation bar. Under iOS 18 everything lines up as expected. To demonstrate, create a new iOS project based on Swift/Storyboard. Setup the storyboard to show a UINavigationController with one UIViewController. Then in ViewController.swift (the one embedded in the navigation controller), use the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .yellow title = "Layout Margins" let leftCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.leftBarButtonItem = leftCancel let rightCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.rightBarButtonItem = rightCancel let leftView = UIView() leftView.backgroundColor = .blue leftView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(leftView) let rightView = UIView() rightView.backgroundColor = .red rightView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(rightView) NSLayoutConstraint.activate([ leftView.widthAnchor.constraint(equalToConstant: 80), leftView.heightAnchor.constraint(equalToConstant: 80), leftView.leadingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.leadingAnchor), leftView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), rightView.widthAnchor.constraint(equalToConstant: 80), rightView.heightAnchor.constraint(equalToConstant: 80), rightView.trailingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.trailingAnchor), rightView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), ]) } } This adds a "Cancel" button to both ends of the navigation bar and it adds two little square views lined up with the leading and trailing layout margins. Here's the results: iPad running iPadOS 26 beta 3 (note the misalignment). This is really jarring when trying to align another glass button below the cancel button: iPad running iPadOS 18.5 (aligned just fine): iPhone in portrait running iOS 26 beta (aligned just fine): iPhone in landscape running iOS 26 beta (no alignment at all): iPhone in portrait running iOS 18.5 (aligned just fine): iPhone in landscape running iOS 18.5 (aligned just fine): Under iOS 26 on an iPhone (simulator at least) in portrait, the cancel buttons line up with the colored squares. That's good. In landscape, the colored squares have much larger margins as expected (due to the larger safe areas caused by the notch), but the cancel buttons in the navigation bar are not using the same margins. This one is debatable. Under iOS 18 the cancel buttons use larger margins to match the larger safe area. But I can see why under iOS 26 they changed this since the navigation bar doesn't interfere with the notch. But it's inconsistent. Under iOS 26 on an iPad (simulator at least), it's wrong in any orientation. Despite the lack of any notch or need for a larger safe area, the colored squares are indented just a bit more than the buttons in the navigation bar. I see no reason for this. Under iOS 18 everything lines up as expected. My real question at this point: Is the mismatched margins on an iPad under iOS 26 between the buttons in the navigation bar and other views added to the view controller a likely bug or am I missing something?

Is anyone else using one of the "Dark" editor themes (such as "Default (Dark)" or "Classic (Dark)" in Xcode? And is anyone doing this with Xcode 26 on macOS 26? Here's the result while using the "Default (Dark)" theme while my Mac is in "light" mode: Note that the black background of the editor goes all the way to the far left edge of the Xcode window. The large gray area in the project tree is the black background bleeding through the sidebar. This is really distracting. Is there a way to fix this (besides not using a dark theme - I've been using dark themes for over 30 years)? This appears to be a poor design decision in macOS 26 to have split views show the background of the secondary column behind the primary column. iPadOS 26 has the same issue (see https://developer.apple.com/forums/thread/800073).

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.