@Etresoft The goal is to use older Asset Catalog based app icons for pre-26, and new Icon Composer based app icons for 26+. With Xcode 26.0, you could make it work using the --enable-icon-stack-fallback-generation=disabled setting. But as of Xcode 26.1, that setting is now being ignored and when the app is run, the Icon Composer based app icon is used for all versions, pre and post 26. While this thread is about macOS, it equally applies to iOS apps. I'm sticking with Xcode 26.0 because I want my old app icons for iOS 18 and older. Xcode 26.1 is now preventing this from being possible.

@KayleeSC I've been having the same issue for over a year, at least. Just today I got a reply to one of my bug reports. This time, instead of just clicking on the "Add More Information" button at the end of the report, I clicked on the "Reply to Apple Feedback" link at the bottom of the reply from Apple. After submitting the requested information, in this case confirming that the issue is now resolved, the report still had the purple dot next to it. But as soon as I closed the report (which was appropriate in this case), the purple dot disappeared and the feedback moved from the "Requests" folder back to my "Submitted" folder. So yes, this is a bug in Feedback Assistant. You really should file a bug report on this.

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

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.

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.

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.

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

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

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.

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.

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

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.

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

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.