@soapbox Make sure you file a bug report using Feedback Assistant.

This sounds like the issue being discussed here: https://developer.apple.com/forums/thread/803019 This has been fixed in macOS 26.1 which will likely be released today.

Are all of you posting bug reports with Feedback Assistant? Make sure you do. Be sure your report includes the steps needed to reproduce the issue and include the sysdiagnose attachment. What version of macOS is everyone seeing this issue with? In my case I'm running macOS 26.0.1. I don't know if the version of macOS matters or not. I see the issue with both Xcode 26 and Xcode 26.1. It's just requires starting an iOS/iPadOS 26.1 simulator. I have no issue when running an iOS/iPadOS 26.0 simulator.

There is an existing thread on this issue. See https://developer.apple.com/forums/thread/805625

There's no macOS-like menu bar when the user chooses "Full Screen Apps". I didn't know this and some of my app's functionality can only be accessed through the main menu bar. So I was thinking I could show some alternative way to access those features when in that mode. iPadOS has supported the ability to open a new scheme through drag and drop using UIDragItem and NSItemProvider and dragging it to the edge of the screen. When a user chooses "Full Screen Apps", this no longer works for opening a new scene. I'd like to disable the drag and drop if it's not going to actually do anything. Those are two main things I can think of so far that depend on the user's choice of multitasking mode.

@Martin81 I get the ReportCrash issue running an iOS 26.1 simulator such as an iPhone 17 Pro. And it is showing a wallpaper. The only sims that don't show a wallpaper in my case are iPad simulators running iPadOS 26.1. But here's what's really weird. I ran the Photos app in the iPhone 17 Pro simulator (which is showing the default wallpaper and causing high CPU). While viewing one of the stock simulator photos I chose "Use as Wallpaper". I went through the steps. Even though the chosen image is now appearing as a black wallpaper, it did fix the high CPU problem for that simulator. Such a strange set of bugs.

Thanks. I'll adjust my UI for the iPad so the main menu isn't required. In the next day I'll work on filing a bug report about #2. A user can still open a second scene using the "New Window" context menu from the app's icon on the home screen, but a new scene can't be created the old way as I described earlier. And there's no way to know with the current API so it leaves the user wondering what this "useless drag feature" is for.

This is still an issue with iOS/iPadOS 26.2 beta 1. I'm getting comments from users of my app due to this bug that has been around since iOS/iPadOS 26.0 beta 1. Apple, please fix all of the issues related to search scope buttons.

All of these are still an issue with iPadOS 26.2 beta 1.

I found a work around for this issue. I'm annoyed I didn't think of this months ago. Instead of setting up the scope bar titles at the start, wait until the search controller is about to be activated the first time. In the code in my original post, remove these lines from setupSearch: let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] and add the line: search.delegate = self Then add the following extension to the view controller class: extension ViewController: UISearchControllerDelegate { func willPresentSearchController(_ searchController: UISearchController) { if searchController.searchBar.scopeButtonTitles == nil { searchController.searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] } } } This change works under iOS/iPadOS 26.0 and later. Now the scope buttons do not interfere with whatever content is immediately below the search bar.

There are various reports of this issue scattered about. Any time I start to hear the crackle I run the following command from a terminal window: sudo pkill coreaudiod That fixes the issue for a while. If you run that while playing music or other audio, the sound will stop for a couple of seconds as the process restarts and then the audio will come back without the crackle.

I hadn't noticed this issue before but I just tested with my app running on an iPad with iPadOS 26.2 beta 1 and this problem still exists. It's fine with iPadOS 26.0. So it's a regression in iPadOS 26.1 that still exists in 26.2. What's strange about this issue is that it only seems to be the userInterfaceStyle (light/dark). My app has a custom trait that can be applied to the scene's main window. And I can change that trait while a popover is in view. If the custom trait is changed it happily propagates to all view controllers, including the popover.

It's definitely iOS/iPadOS 26 bugs that have been there since 26.0 beta 1. It's really annoying. It makes it really difficult to know if it's your own code or not when the console fills up with constant errors coming from the OS and not your own code. The whole new look in iOS 26 is nice, but the constant bugs and junk like these extraneous error messages are making it harder and harder to enjoy working with Apple's tools and platforms.

You just have to use Xcode to put an updated version of the app on your iOS device once in a while. That's normal. Even as a paid app developer, development builds have a limited time before they expire. Just connect the device and run the app through Xcode again. The only way you can create an app that runs forever on an iOS device is to install the app through the App Store. But that requires you to be a paid developer and your app needs to be something usable by many people and reviewed and approved by Apple. Even apps loaded via Test Flight only last 90 days.

I've paid $99/year every year since 2008. Given inflation, the developer program is cheaper every year (so far any way).