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.

Hello, I’m seeing a layout issue where the system window controls overlap the navigation bar’s right-side buttons when the app window is resized on iPadOS 26. Environment Xcode: 16.4 Simulator: iPadOS 26.0, device profile iPad Pro 13-inch Physical device: iPad updated to iPadOS 26 (same behavior) UI stack: UIKit + Storyboards (no SwiftUI) App structure: Root UINavigationController Summary Since iPadOS 26 introduced freely resizable app windows, the system’s window management controls (close/minimize/resize at the top-right) begin to overlap the navigation bar buttons as the window size becomes smaller. At maximum window size there’s no issue. Additionally, the navigation bar buttons themselves appear to scale down visually when the window gets smaller. Steps to Reproduce Build with Xcode 16.4 and run on iPadOS 26.0 (simulator or device). Open a screen embedded in a UINavigationController with right-side bar button items. Resize the app window to a smaller size. Observe the top-right system window controls overlapping the navigation bar buttons. Expected Result System window controls should not overlap app content; the navigation bar should remain usable and properly spaced at all supported window sizes. Actual Result When the window is small, the system window controls overlap the right-side navigation bar buttons. The bar button items also appear to shrink as the window size decreases. Notes Reproducible on both simulator and a real device updated to iPadOS 26. Project uses UIKit + Storyboards only (no SwiftUI). Safe areas and basic constraints look fine, so the root cause is unclear. Questions Is this a known issue with iPadOS 26 resizable windows? Any recommended workaround (e.g., API to reserve space near the window controls, UINavigationBar configuration, or trait/size-class handling)? I can provide a minimal sample project and screenshots if helpful. Thank you!

The iPad Pro on iPadOS 26 now operates on the same class of silicon as Apple’s entry-level Macs. It ships with M-series processors, 8GB of unified memory, support for multiple resizable windows, a menu bar, and proper external display connections. The device already has the foundation required for professional software development. The only gap is the absence of Xcode. Making the full version of Xcode available on iPad Pro would not take away from the Mac. Large and resource-intensive projects will still require the power of MacBook Pro and Mac Studio. What it would do is allow smaller and mid-sized projects to be developed directly on iPad Pro, which the hardware is fully capable of handling. That dynamic is complementary, not cannibalizing. Developers would continue to buy Macs but would also buy iPad Pros for portability and flexibility. The revenue upside is clear. Lowering the entry barrier means more developers enrolling in the Apple Developer Program at $99 per year, creating predictable recurring subscription income. A wider developer base leads to more apps reaching the App Store. Even if many are small, Apple benefits from every transaction through its revenue share. This strengthens the services business, which already delivers the company’s highest margins. There is also a direct hardware impact. Once Xcode is available, iPad Pro will be recognized as a legitimate professional development device. That drives more unit sales of a high-margin product line and increases attachment rates for accessories like the Magic Keyboard, Apple Pencil, and external monitors. Instead of eroding Mac sales, the effect is expansion. Developers will own both devices. The case is straightforward. The hardware is ready. The operating system is ready. Enabling full Xcode on iPad Pro would expand the developer funnel, grow recurring subscription revenue, increase App Store volume, and boost high-margin hardware and accessory sales. It is a decision that benefits developers, strengthens the ecosystem, and maximizes profit.

We’ve encountered an issue while developing with SwiftUI: when using the inspector on iPadOS, if the inspector is placed inside a NavigationStack, and both the view attached to the inspector and the content inside the inspector itself are scrollable, scrolling them to the top may cause abnormal jitter. We suspect this issue might be related to NavigationTitle. However, if we place the inspector outside the NavigationStack, tapping any NavigationLink while the inspector is expanded will cause problems with the View.matchedTransitionSource(id:in:) animation. A reproducible project can be found here: https://github.com/ThreeManager785/Inspetor-Issue We’ve tried many approaches but haven’t been able to resolve it. Is there any way to fix this issue?

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?

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.

This is really odd. If you setup a UISearchController with a preferredSearchBarPlacement of .stacked and you setup the search bar with scope buttons, then when the view controller is initially displayed, the currently hidden scope buttons block touch events from reaching the main view just below the search bar. But once the search is activated and dismissed, then the freshly hidden scope buttons no longer cause an issue. This is easily demonstrated by putting a UITableViewController in a UINavigationController. Setup the table view to show a few simple rows. Then setup a search controller using the following code: func setupSearch() { // Setup a stacked search bar with scope buttons // Before the search is ever activated, the hidden scope buttons block any touches in the main view controller // in the area just below the search bar. // Once the search is activated and dismissed, the problem goes away. It seems that displaying and hiding the // scope buttons at least once fixes the issue that exists beforehand. // This issue only exists in iOS/iPadOS 26, not iOS/iPadOS 18 or earlier. let search = UISearchController(searchResultsController: UIViewController()) search.hidesNavigationBarDuringPresentation = true search.obscuresBackgroundDuringPresentation = true search.scopeBarActivation = .onSearchActivation // Ensure button appear immediately let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] self.navigationItem.searchController = search self.navigationItem.hidesSearchBarWhenScrolling = false // Issue appears even if this is true self.navigationItem.preferredSearchBarPlacement = .stacked } When first shown, before any attempt is made to activate the search, any attempt to tap on the upper 2/3 of the first row in the table view (which is just below the search bar) fails. If you tap on the lower 1/3 of the first row it works fine. If you then activate the search (now the scope buttons appear) and then dismiss the search (now the scope buttons are hidden again), then there is no issue tapping anywhere on the first row of the table. But if you restart the app, the problem starts over again. This problem happens on any iPhone or iPad, real or simulated, running iOS/iPadOS 26 RC. This is a regression from iOS 18 or earlier.

When trying to use a UISearchController setup with a UISearchBar that has scope buttons, the search controller's scopeBarActivation property is set to .onSearchActivation, the navigation item's preferredSearchBarPlacement property is set to .integrated. or .integratedButton, and the search bar/button appears in the navigation bar, then the scope buttons never appear. But space is made for where they should appear. Some relevant code in a UIViewController shown as the root view controller of a UINavigationController: private func setupSearch() { let sc = UISearchController(searchResultsController: UIViewController()) sc.delegate = self sc.obscuresBackgroundDuringPresentation = true // Setup search bar with scope buttons let bar = sc.searchBar bar.scopeButtonTitles = [ "One", "Two", "Three", "Four" ] bar.selectedScopeButtonIndex = 0 bar.delegate = self // Apply the search controller to the nav bar navigationItem.searchController = sc // BUG - Under iOS/iPadOS 26 RC, using .onSearchActivation results in the scope buttons never appearing at all // when using integrated placement in the nav bar. // Ensure the scope buttons appear immediately upon activating the search controller sc.scopeBarActivation = .onSearchActivation // This works but doesn't show the scope buttons until the user starts typing - that's too late for my needs //sc.scopeBarActivation = .automatic if #available(iOS 26.0, *) { // Under iOS 26 put the search icon in the nav bar - same issue for .integrated and .integratedButton navigationItem.preferredSearchBarPlacement = .integrated // .integratedButton // My toolbar is full so I need the search in the navigation bar navigationItem.searchBarPlacementAllowsToolbarIntegration = false // Ensure it's in the nav bar } else { // Under iOS 18 put the search bar in the nav bar below the title navigationItem.preferredSearchBarPlacement = .stacked } } I need the search bar in the navigation bar since the toolbar is full. And I need the scope buttons to appear immediately upon search activation. This problem happens on any real or simulated iPhone or iPad running iOS/iPadOS 26 RC.

Hi, it seems like using Table on iPadOS 26 results in the table header not applying a background. When comparing the same code on iPadOS 18, the table header applies a blur behind the header to ensure legibility when the user scrolls the content. Is there a way to ensure Table applies a background effect to the header so that content remains legible during scrolling? Here is a minimal example: struct TablePreviewContent: Identifiable { var id: Int { text.hashValue } var text: String } #Preview { let content = [TablePreviewContent(text: "Hello"), TablePreviewContent(text: "World")] Table(content) { TableColumn("Title", value: \.text) } } I've attached screenshots of the behavior on iPadOS 26 compared to iPadOS 18 to illustrate the issue.

Hi, I have a ninth generation iPad updated to iPados 26 beta 3 but now it no longer updates to the latest version of iPados 26, what can I do?

My app controls the cursor movement in a text view on iPhone and iPads. On screen touch, the IOS cursor position is out of sync with the app cursor position. Is there a way to find out, on screen touch, where the ios cursor positition is and update the app cursor to the ios cursor position? When they are out of sync, the user has to move the cursor to the startIndex and navigate from there. Frustating! I have looked at many programming books, forums, and internet search with nothing to no avail. Any help will be greatly appreciated. The app names are SummaGramPhonex and SummaGramIPAD11 and SummaGramIPAD13. Thanks. Charlie 3Sep25

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?

When changing a camera's exposure, AVFoundation provides a callback which offers the timestamp of the first frame captured with the new exposure duration: AVCaptureDevice.setExposureModeCustom(duration:, iso:, completionHandler:). I want to get a similar callback when changing frame duration. After setting AVCaptureDevice.activeVideoMinFrameDuration or AVCaptureDevice.activeVideoMinFrameDuration to a new value, how can I compute the index or the timestamp of the first camera frame which was captured using the newly set frame duration?

How can we receive the iPadOS 18.6.1 update on an iPad? We have configured the MDM update days policy to receive recent, but not the latest, iPadOS updates; however, we are only able to get versions 18.6.2 and 18.6. Is the availability of iPadOS updates dependent on the iPad's region? Thank you in advance for your assistance.

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()) ]

In our app we have a UICollectionView with Drag&Drop functionality enable and collection view is covering the entire screen. When we drag a collection view item to the edge of the screen it does not scroll the UICollectionView instead that our item turns into the app icon and scrolling blocked. It is happening only if Stage Manager is enabled in the device and if Stage Manager is disabled it is working fine. This issue we are facing after iOS 18.6 release, before 18.6 it was working fine i.e, collection view was scrolling to next items when we dragging an item to edge of the screen, similar to the iOS calendar app when we drag an event to edge it starts scrolling the date. And in iOS 26 if we drag an item to edge, Springboard is getting crashed.

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, I'm updating my iPhone app (iPhone only) to be ready with iOS 26. I'm building my app using Xcode 26.0 beta 6 (17A5305f) and testing it on an iPad running iPadOS 26 (23A5326a). I found an issue with my new app icon updated using Icon Composer and I was able to find the issue. An iPhone only app running on iPadOS 26 doesn't use the provided app icon. It always displays the "standard" light icon. I just added iPad in Supported Destinations and the app icon now respect light/dark/translucent/tinted modes on the Home Screen. I submitted feedback FB19768667

How can I remove the "recents" section from long-pressing on my app icon? I've added the following to my AppDelegate, which removes it from the top MenuBar, but not from the app icon context menu. My app has registered a custom filetype, but it is not a document based app. Opening files imports them into the app's user library, and so does not make sense to have a "recents" list. override func buildMenu(with builder: any UIMenuBuilder) { super.buildMenu(with: builder) builder.remove(menu: .openRecent) }

On the iPad Pro 12.9-inch (3rd generation) cellular model, when you touch the screen with four fingers and then move your fingers, the touch is no longer detected. The same operation with one to three fingers works normally. This phenomenon does not occur when accessibility is turned on. Is this a beta-specific issue that will be fixed in the official release?