Hello, my iOS apps are exiting right after launch on a few of our iOS devices. I tried a couple of my apps that are deployed to our fleet and they do the same thing. If I run the app(s) in the Simulator it works fine and if I run the app(s) on the offending devices it works fine as well. Once I stop the run in Xcode the app on the device will not launch. I'm thinking something is missing like a certificate etc. Just not sure. Any ideas on how to troubleshoot this? I would really like to get this fixed.

We've identified a regression in iOS 26.0 and 26.1 Beta 4 where AVSpeechSynthesisVoice(language:) no longer respects user-selected voices from Accessibility settings. Issue: When users select a specific voice in Settings → Accessibility → Spoken Content → Voices, calling AVSpeechSynthesisVoice(language:) returns the system default voice instead of the user's selection. This worked correctly in iOS 18.6.2. Particularly affects: Third-party speech synthesis voices (CereProc, Grammatek, etc.) Apps relying on automatic voice selection based on user preferences Example: // User selected CereProc Heather for en-GB in Accessibility settings let voice = AVSpeechSynthesisVoice(language: "en-GB") print(voice?.name) // iOS 18.6.2: "HEATHER", iOS 26: "Daniel" (system default) Interesting observation: The new Accessibility Reader feature in iOS 26 correctly uses the user-selected voice, but Tap to Speak and the API both ignore the setting. Tested methods: AVSpeechSynthesisVoice(language:) AVSpeechUtterance auto-selection Reflection for new APIs All return the system default voice, not the user's preference. Filed: FB[20271264] Has anyone else encountered this? Any known workarounds to programmatically access the user's preferred voice selection?

I'm trying to create a UI with two button bars (top and bottom) inside the detail view of a NavigationSplitView, instead of using the built-in .toolbar() modifier. I'm using .ignoresSafeArea(.container, edges: .vertical) so the detail view can reach into that area. However, in macOS and iOS 26 the top button is not clickable/tappable because it is behind an invisible View created by the non-existent toolbar. Interestingly enough, if I apply .buttonStyle(.borderless) to the top button it becomes clickable (in macOS). On the iPad the behavior is different depending on the iPad OS version. In iOS 26, the button is tappable only by the bottom half. In iOS 18 the button is always tappable. Here's the code for the screenshot: import SwiftUI struct ContentView2: View { @State private var sidebarSelection: String? @State private var contentSelection: String? @State private var showContentColumn = true @State private var showBars = true var body: some View { NavigationSplitView { // Sidebar List(selection: $sidebarSelection) { Text("Show Content Column").tag("three") Text("Hide Content Column").tag("two") } .navigationTitle("Sidebar") } detail: { VStack(spacing: 0) { if showBars { HStack { Button("Click Me") { withAnimation { showBars.toggle() } } .buttonStyle(.borderedProminent) } .frame(maxWidth: .infinity, minHeight: 50, idealHeight: 50, maxHeight: 50) .background(.gray) .transition(.move(edge: .top)) } ZStack { Text("Detail View") } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .init(horizontal: .center, vertical: .center)) .border(.red) .onTapGesture(count: 2) { withAnimation { showBars.toggle() } } if showBars { HStack { Button("Click Me") { withAnimation { showBars.toggle() } } } .frame(maxWidth: .infinity, minHeight: 50, idealHeight: 50, maxHeight: 50) .background(.gray) .transition(.move(edge: .bottom)) } } .ignoresSafeArea(.container, edges: .vertical) .toolbarVisibility(.hidden) } .toolbarVisibility(.visible) } } I'm confused by this very inconsistent behavior and I haven't been able to find a way to get this UI to work across both platforms. Does anybody know how to remove the transparent toolbar that is preventing clicks/taps in this top section of the view? I'm hoping there's an idiomatic, native SwiftUI way to do it.

Hi everyone I'm experiencing an issue with iPadOS 26 regarding multi-touch gesture detection. When performing a quick four-finger gesture (tap and swipe), the system often fails to recognize the input. This especially affects multi-touch gestures, such as rhythm games with difficult levels. Steps to Reproduce: Place four fingers on the screen. Perform a quick tap or a quick horizontal swipe (like the one used to switch apps). Observe whether the gesture is ignored or detected inconsistently. Expected Behavior: 4-finger multitouch gestures should be recognized regardless of gesture speed, just like previous iPadOS versions. Actual Behavior: Gestures fail to be detected when executed quickly—same gestures still work, and miss notes in rhythm games. You can check out my posts on Twitter/x and Facebook: [https://x.com/kokona_fwa/status/1978131164104728949?s=61] Facebook: [https://m.facebook.com/groups/idipad/permalink/24438964899058806/?]

With macOS Tahoe, Launchpad has been replaced by an App Library–style mode within Spotlight. While the alleged intention is UX consistency across the Apple ecosystem, the result is both a catastrophic usability regression and a radical break in consistency with iOS and iPadOS. Predefined App Library categorization is functionally incoherent: On iOS and now macOS, Apple’s predefined App Library categories place apps with seemingly identical functionality into unrelated groups—for example, 3D scanning tools scattered across Education, Utilities, and Productivity. Instead of making apps easier to find, this effectively creates a labyrinth that users must traverse to locate apps whose names and icons they may not recall. However Apple defines its app categories, they are not only inconsistent but also hopelessly inadequate for the long tail of real-world applications and user workflows. Loss of user control: Launchpad enabled users to group and organize applications according to their workflows. This aligns with Apple’s own Human Interface Guidelines, which emphasize user control, discoverability, and predictable behavior. The new Spotlight interface removes that flexibility, locking users into predefined categories that both impede and mislead—and cannot be overridden. Consistency across platforms is broken: If the goal was to unify iOS, iPadOS, and macOS, this approach actually undermines consistency. On iOS and iPadOS, users can still rely on a customizable Home Screen—a Launchpad-like experience—as their primary way of launching apps. In Tahoe, that option has been removed. macOS now forces users to depend exclusively on Spotlight with App Library categories, while eliminating the very feature that was consistent across platforms. Catastrophic impact on my workflow: As an interdisciplinary artist working in 2D, 3D, and time-based media, as well as coding, I make extensive use of a constantly changing array of AI tools and experiment with many new apps and web services, which I often turn into Web Apps. I cannot possibly recall the names of every native and web app on my system. I need predictable access to groups of related tools. Tahoe’s new auto-categories split those apps apart arbitrarily, slowing me down and interrupting established workflows, forcing me to navigate the aforementioned labyrinth just to find what I need. Proposal: A constructive way forward High-level objective: Simply restore Launchpad—or restore the ability to customize app categories/folders and manually assign apps to them, overriding or augmenting the predefined categories. This ensures users can launch apps according to their workflow, without needing to remember exact names or icons. Possible solutions: Allow manual subfolders within Applications, represented hierarchically in Spotlight. Provide a fullscreen Launchpad-like organizer (with uninstall via long-click, etc.), either as a replacement or toggleable option. Retain Apple’s auto-categories for those who prefer them, but let users override or augment them with their own. In summary: Tahoe eliminates a working, consistent paradigm (Launchpad/Home Screen) and forces reliance on an App Library system that categorizes poorly and cannot be customized. This is both a step backwards in functionality and a break in cross-platform consistency. A constructive solution is to restore Launchpad—or at least restore the ability for users to organize apps in ways that fit their workflows.

Under iPadsOS 26.0 and 26.1, if a view controller is presented with a presentation style of fullScreen or pageSheet, and the view controller is setup with a UISearchController that has obscuresBackgroundDuringPresentation set to true, then when cancelling the search the view controller is being dismissed when it should not be. To replicate, create a new iOS project based on Swift/Storyboard using Xcode 26.0 or Xcode 26.1. Update ViewController.swift with the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground title = "Root" navigationItem.rightBarButtonItems = [ UIBarButtonItem(title: "Full", primaryAction: .init(handler: { _ in self.showModal(with: .fullScreen) })), UIBarButtonItem(title: "Page", primaryAction: .init(handler: { _ in self.showModal(with: .pageSheet) })), UIBarButtonItem(title: "Form", primaryAction: .init(handler: { _ in self.showModal(with: .formSheet) })), ] } private func showModal(with style: UIModalPresentationStyle) { let vc = ModalViewController() let nc = UINavigationController(rootViewController: vc) // This triggers the double dismiss bug when set to either pageSheet or fullScreen. // If set to formSheet then it works fine. // Bug is only on iPad with iPadOS 26.0 or 26.1 beta 2. // Works fine on iPhone (any iOS) and iPadOS 18 as well as macOS 26.0 (not tested with other versions of macOS). nc.modalPresentationStyle = style self.present(nc, animated: true) } } Then add a new file named ModalViewController.swift with the following code: import UIKit class ModalViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() title = "Modal" view.backgroundColor = .systemBackground setupSearch() } private func setupSearch() { let sc = UISearchController(searchResultsController: UIViewController()) sc.delegate = self // Just for debugging - being set or not does not affect the bug sc.obscuresBackgroundDuringPresentation = true // Critical to reproducing the bug navigationItem.searchController = sc navigationItem.preferredSearchBarPlacement = .stacked } // When the search is cancelled by tapping on the grayed out area below the search bar, // this is called twice when it should only be called once. This happens only if the // view controller is presented with a fullScreen or pageSheet presentation style. // The end result is that the first call properly dismisses the search controller. // The second call results in this view controller being dismissed when it should not be. override func dismiss(animated flag: Bool, completion: (() -> Void)? = nil) { print("dismiss ViewController") // Set breakpoint on the following line super.dismiss(animated: flag, completion: completion) } } extension ModalViewController: UISearchControllerDelegate { func willDismissSearchController(_ searchController: UISearchController) { print("willDissmissSearchController") } func didDismissSearchController(_ searchController: UISearchController) { print("didDismissSearchController") } } Build and run the app on a simulated or real iPad running iPadOS 26.0 or 26.1 (beta 2). A root window appears with 3 buttons in the navbar. Each button displays the same view controller but with a different modalPresentationStyle. Tap the Form button. This displays a modal view controller with formSheet style. Tap on the search field. Then tap on the grayed out area of the view controller to cancel the search. This all works just fine. Dismiss the modal (drag it down). Now tap either the Page or Full button. These display the same modal view controller with pageSheet or fullScreen style respectively. Tap on the search field. Then tap on the grayed out area of the view controller to cancel the search. This time, not only is the search cancelled, but the view controller is also dismissed. This is because the view controller’s dismiss(animated:completion:) method is being called twice. See ViewController.swift for the code that presents the modal. See ModalViewController.swift for the code that sets up the search controller. Both contain lots of comments. Besides the use of fullScreen or pageSheet presentation style to reproduce the bug, the search controller must also have its obscuresBackgroundDuringPresentation property set to true. It’s the tap on that obscured background to cancel the search that results in the double call to dismiss. With the breakpoint set in the overloaded dismiss(animated:completion:) function, you can see the two stack traces that lead to the call to dismiss. When presented as a formSheet, the 2nd call to dismiss is not being made. This issue does not affect iPadOS 18 nor any version of iOS on iPhones. Nor does it affect the app using Mac Catalyst on macOS 26.0 (untested with macOS 15 or 26.1). In short, it is expected that cancelling the search in a presented view controller should not also result in the view controller being dismissed. Tested with Xcode 26.1 beta 2 and Xcode 26.0. Tested with iPadOS 26.1 beta 2 (real and simulated) and iPadOS 26.0 (simulated). A version of this post was submitted as FB20569327

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.

Hi all, Sharing a reproducible UIKit issue I’m seeing across multiple iPadOS 26 betas, with a tiny sample attached and a short video. Short video https://youtu.be/QekYNnHsfYk Tiny project https://github.com/yoasha/ListSwipeOvershootReproSwift Summary In a UISplitViewController (.doubleColumn), a UICollectionView using list layout shows a large leading-swipe overshoot when the split view is expanded (isCollapsed == false). The cell content translates roughly 3–4× the action width. Repros with appearance = .plain and .grouped Does not repro with .insetGrouped Independent of trailing provider (issue persists when trailing provider is nil) Collapsed split (compact width) behaves correctly Environment Devices: iPad Air (3rd gen), iPadOS 26.0 (23A5326a) → Repro Simulators: iPad Pro 11-inch (M4), iPadOS 26.0 beta 6 → Repro Also tested on device: iPadOS 26 beta 5, 6, 7, 8 Xcode: 26.0 beta 6 (17A5305f) Steps to reproduce Launch the sample; ensure the split is expanded (isCollapsed == false). In the secondary list, set Appearance = Plain (also repros with Grouped). Perform a leading swipe (LTR: swipe right) on any row. Actual: content shifts ~3–4× the action width (overshoot). Expected: content translates exactly the action width. Switch Appearance = InsetGrouped and repeat the leading (swipe right) gesture → correct (no overshoot). Feedback Assistant FB ID: FB19785883 (full report + attachments filed; this forum thread mirrors the repro for wider visibility) Minimal code (core of the sample) If anyone from Apple needs additional traces or a sysdiagnose, I can attach promptly. Thanks! // Secondary column VC (snippet) var cfg = UICollectionLayoutListConfiguration(appearance: .plain) // also .grouped / .insetGrouped cfg.showsSeparators = true cfg.headerMode = .none cfg.leadingSwipeActionsConfigurationProvider = { _ in let read = UIContextualAction(style: .normal, title: "Read") { _,_,done in done(true) } read.backgroundColor = .systemBlue let s = UISwipeActionsConfiguration(actions: [read]) s.performsFirstActionWithFullSwipe = false return s } // Trailing provider can be nil and the bug still repros for leading swipe: cfg.trailingSwipeActionsConfigurationProvider = nil let layout = UICollectionViewCompositionalLayout.list(using: cfg) let collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: layout) // … standard data source with UICollectionViewListCell + UIListContentConfiguration // Split setup (snippet) let split = UISplitViewController(style: .doubleColumn) split.preferredDisplayMode = .oneBesideSecondary split.viewControllers = [ UINavigationController(rootViewController: PrimaryTableViewController()), UINavigationController(rootViewController: SecondaryListViewController()) ]

Is the Cancel button intentionally removed from UISearchBar (right side)? Even when using searchController with navigationItem also. showsCancelButton = true doesn’t display the cancel button. Also: When tapping the clear ("x") button inside the search field, the search is getting canceled, and searchBarCancelButtonClicked(_:) is triggered (Generally it should only clear text, not cancel search). If the search text is empty and I tap outside the search bar, the search is canceled. Also when I have tableview in my controller(like recent searches) below search bar and if I try to tap when editing started, action is not triggered(verified in sample too). Just cancellation is happening. In a split view controller, if the search is on the right side and I try to open the side panel, the search also gets canceled. Are these behaviors intentional changes, beta issues, or are we missing something in implementation?

Our project using UISplitViewController as the root view controller for whole app. And when using the xocde26 to build app in iOS26, the layout of page is uncorrect. for iPhone, when launch app and in portrait mode, the app only show a blank page: and when rotate app to landscape, the first view controller of UISplitViewController's viewControllers will float on second view controller: and this float behavior also happens in iPad: below is the demo code: AppDelegate.swift: import UIKit @main class AppDelegate: UIResponder, UIApplicationDelegate { let window: UIWindow = UIWindow() func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { let vc = SplitViewController(primary: TabBarViewController(), secondary: ViewController()) window.rootViewController = vc window.makeKeyAndVisible() return true } } SplitViewController: import UIKit class SplitViewController: UISplitViewController { init(primary: UIViewController, secondary: UIViewController) { super.init(nibName: nil, bundle: nil) preferredDisplayMode = .oneBesideSecondary presentsWithGesture = false delegate = self viewControllers = [primary, secondary] } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func viewDidLoad() { super.viewDidLoad() } } extension SplitViewController: UISplitViewControllerDelegate { } TabBarViewController.swift: import UIKit class FirstViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .red tabBarItem = UITabBarItem(title: "Home", image: UIImage(systemName: "house"), tag: 0) } } class SecondViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .purple tabBarItem = UITabBarItem(title: "Setting", image: UIImage(systemName: "gear"), tag: 1) } } class TabBarViewController: UITabBarController { override func viewDidLoad() { super.viewDidLoad() let firstVC = FirstViewController() let secondVC = SecondViewController() tabBar.backgroundColor = .orange viewControllers = [firstVC, secondVC] } } ViewController.swift: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemPink } } And I have post a feedback in Feedback Assistant(id: FB18004520), the demo project code can be found there.

I’m experiencing a strange issue with the App Switcher on my iPad. When I swipe up from the bottom to open the App Switcher, the apps that should be running sometimes don’t appear — they briefly flash for a split second and then disappear. The App Switcher itself stays open, but it shows no app cards. Here are some details: Device: iPad Pro (11-inch, 2nd generation) iPadOS version: 26.0.1 Reproducibility: Happens intermittently Steps to reproduce: Open several apps. Swipe up from the bottom and pause to show the App Switcher. Sometimes, the app cards flash for a moment and then disappear, leaving the App Switcher empty. Expected behavior: The App Switcher should display all running apps consistently. Actual behavior: The App Switcher appears, but the app cards briefly flash and disappear, leaving a blank screen. I’ve seen a few similar reports on the Apple Support Community, but I’m not sure if this is a known issue in iPadOS 26.0.1. Has anyone else encountered this problem? Any confirmations or workarounds would be appreciated. Thank you in advance!

We are observing that for devices with iPadOS 26, table views within apps are unexpectedly auto scrolling. The issue can be reproduced as follows: The table view has enough cells to the point where not all cells can fit on the screen and the table view is scrollable User has scrolled to the bottom of the tableView and tableView.reloadData() is called. One of the following applies: The ViewController containing the tableView is embedded in a UINavigationController, and ViewController sets self.edgesForExtendedLayout = .bottom The ViewController containing the tableView is embedded in a UINavigationController, and UINavigationController sets navigationBar.isTranslucent = false The following constraints are applied to the tableView: tableView.topAnchor.constraint(equalTo: view.layoutMarginsGuide.topAnchor).isActive = true tableView.leftAnchor.constraint(equalTo: view.leftAnchor).isActive = true tableView.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true tableView.rightAnchor.constraint(equalTo: view.rightAnchor).isActive = true After thorough testing, we've found that the bug is only present in iPads with iPadOS 26. It does not show for iPhone devices or for iPads on iPadOS 18. We are hoping that this can be fixed as it is causing poor user experience. Full code needed to reproduce the issue: Use this willConnectTo function in SceneDelegate: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } window = UIWindow(windowScene: windowScene) let navigationControllerWithVC = UINavigationController(rootViewController: ViewController()) // ⚠️ CASE 1 - Comment out the .isTranslucent setter below, or set the value to true, and the scrolling issue will be gone, granted that the other issue-causing lines in ViewController.swift // are also commented. navigationControllerWithVC.navigationBar.isTranslucent = false window?.rootViewController = navigationControllerWithVC // Replace this line with window?.rootViewController = ViewController() to get rid of UINavigationController window?.makeKeyAndVisible() } Use this ViewController class that is referenced from the SceneDelegate willConnectTo function: import UIKit class ViewController: UIViewController, UITableViewDelegate, UITableViewDataSource { var tableView: UITableView! var safeArea: UILayoutGuide! var timer: Timer! override func viewDidLoad() { super.viewDidLoad() // ⚠️ CASE 2 - Uncomment the line below when this view is inside a UINavigationController to cause the scrolling issue. //self.edgesForExtendedLayout = .bottom tableView = UITableView() safeArea = view.layoutMarginsGuide setupTableView() timer = Timer.scheduledTimer(timeInterval: 3.0, target: self, selector: #selector(fireTimer), userInfo: nil, repeats: true) } @objc public func fireTimer() { tableView.reloadData() print("Reloaded table") } func setupTableView() { tableView.delegate = self tableView.dataSource = self view.addSubview(tableView) tableView.translatesAutoresizingMaskIntoConstraints = false // ⚠️ CASE 3 - Replace view.topAnchor in the next line below with safeArea.topAnchor to see the scrolling issue, regardless if view is inside a UINavigationController. tableView.topAnchor.constraint(equalTo: view.topAnchor).isActive = true tableView.leftAnchor.constraint(equalTo: view.leftAnchor).isActive = true tableView.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true tableView.rightAnchor.constraint(equalTo: view.rightAnchor).isActive = true } func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 40 } public func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat { 50.0 } public func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = UITableViewCell() cell.textLabel?.text = indexPath.row == 39 ? "END" : "Row \(indexPath.row)" return cell } public func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) { tableView.deselectRow(at: indexPath, animated: true) } } For reproducing this on iPadOS 26 simulators, I can confirm that simulators under Xcode 26.0.1 (17A400) and Xcode 26.1 Beta (17B5025f) will show the issue. The issue is present in iPadOS 26 and iPadOS 26.1 beta. I've also submitted Apple Feedback for this (FB20357980) with all this code in a Xcode project.

I have a triple-column UISplitViewController setup in "tile" mode. Each of the 3 columns has a table view controller. Under iPadOS 26, the section headers and row selection in the middle table extends all the way to the left of the screen, behind the primary column. It looks terrible. The documentation for "Adopting Liquid Glass" makes it sound like you can add this behavior by using UIBackgroundExtensionView. But I get this behavior automatically in a UISplitViewController. How do I turn this off? I created a simpler sample using a double-column split view with two table view controllers. Here's a screenshot of the result: Note how the section headers and the row selection appear all the way to the left edge of the screen. I don't want that effect. How do you turn off this effect in a UISplitViewController? Here is the code used to setup the split view and the app's main window: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let winScene = (scene as? UIWindowScene) else { return } let primary = PrimaryViewController(style: .plain) let primaryNC = UINavigationController(rootViewController: primary) let detail = DetailViewController(style: .plain) let detailNC = UINavigationController(rootViewController: detail) let sv = UISplitViewController(style: .doubleColumn) sv.preferredDisplayMode = .oneBesideSecondary sv.preferredSplitBehavior = .tile sv.primaryBackgroundStyle = .none sv.displayModeButtonVisibility = .automatic sv.setViewController(primaryNC, for: .primary) sv.setViewController(detailNC, for: .secondary) let win = UIWindow(windowScene: winScene) win.rootViewController = sv win.makeKeyAndVisible() window = win } The PrimaryViewController and DetailViewController are simple UITableViewController subclasses that only add a few rows and section headers as needed.

After updating my Xcode to the latest, I am unable to download an installed app container from the Xcode Devices screen. This currently works with older versions of Xcode with the same app on the same iPad. This worked with older versions of Xcode on the same MacBook as well (including the Xcode 26 beta before updating to the official release yesterday) The specified file could not be transferred. Domain: com.apple.dt.CoreDeviceError Code: 7000 User Info: { DVTErrorCreationDateKey = "2025-09-18 20:31:01 +0000"; NSURL = "file:///Users/thomsk2/Desktop/com.test.polarisdev%202025-09-18%2015:30.53.744.xcappdata/AppData/Library/Caches/"; } The specified file could not be transferred. Domain: com.apple.dt.CoreDeviceError Code: 7000 User Info: { NSURL = "file:///Users/thomsk2/Desktop/com.test.polarisdev%202025-09-18%2015:30.53.744.xcappdata/AppData/Library/Caches/"; } Failed to perform I/O operations. Domain: com.apple.dt.remoteservices.error Code: 11001 Failure Reason: Cannot open destination file /Users/thomsk2/Desktop/com.test.polarisdev 2025-09-18 15:30.53.744.xcappdata/AppData/Library/Caches/com.apple.dyld/standaloneapp.ios.dyld4: Permission denied System Information macOS Version 15.6.1 (Build 24G90) Xcode 26.0 (24228) (Build 17A324) Timestamp: 2025-09-18T15:31:01-05:00

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.

The app I work on uses WKWebView to render customer data. In iPadOS 26, we observe that there is a delay when resizing the window (and thus the web view) before the content is re-rendered. The same behavior is visible in Safari. For demonstration purposes, consider this test page: https://phet-dev.colorado.edu/html/build-an-atom/0.0.0-3/simple-text-only-test-page.html Initially, the window is small: Then when the window is expanded, the content scales up temporarily: It eventually re-renders to the correct size, but then if you make the window small again, you get (temporarily): Is there anyway around this behavior? We would love to have the content reflow interactively.

Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?

My apps are using UIRequiresFullScreen = YES in the info.plist. Now that this is deprecated for iPadOS 26+, I'm updating my apps and using the UIWindowScene's sizeRestriction property to ensure a certain minimum size of the window. I've enabled all orientations support for iPads in the plist as well as the supportedInterfaceOrientations property of the ViewController. On iPadOS 26, the following line works - windowScene.sizeRestrictrions?.minimumSize = CGSize(480,720) The window does not resize below the above threshold and everything works as expected. However on the iPad simulators for 18.x (with Stage Manager enabled), the above sizeRestrictions property is never set. It shows up as nil even after the views have been laid out. The simulator allows me to drag the window handle and shrink the window to well below the specified threshold, all the way down to a width of 375. Is there anyway I can set the sizeRestrictions for iPadOS 18.x and lower?

are there an api to know this feature is on/off

In iOS Background Execution limits, I see this: When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. However, I see that when I close an app on iPadOS 26 with the red X, the app doesn't appear in the multitasking UI. So are they treated as force closes and prevented from running background tasks?