Thanks. I got so focused on getting this added to the context menu I forgot about the “Paste and Match Style” item appearing in the Edit menu bar. Of course that only helps with the iPadOS 26 and Mac Catalyst versions of the app. For iPhones and for iPads on iPadOS before 26, my only option is to use the context menu. I guess I’ll stick with my buildMenuWithBuilder: approach.

Now that macOS 26 GM is out, and even 26.1 beta is out, where does this all stand? More specifically, does anyone know if using macOS 26 as the host, can we create a macOS 15 VM guest all while allowing us to build and test our apps on both macOS 26 and 15? I still have macOS 15.6 on my only Mac. My app supports macOS 14-26 (well, will support macOS 26 when I can actually test with it). But I have no way to test it in any of the VMs since my app needs a working provisioning profile. Even in a macOS 15 guest on my macOS 15 host, I can't even log into TestFlight to test my app. Will updating to a macOS 26 host allow the macOS 15 guest to at least use TestFlight to download the app for testing? In other words, is there any viable way for a solo developer with one Mac to develop and test a macOS app that runs on more than one version of macOS?

Dual booting (triple in my case - 14/15/26) is not a viable option for Xcode development and testing of an app because different versions of macOS support different versions of Xcode. While Xcode 26.0.1 currently runs on macOS 26 and macOS 15.6, it certainly can't be run on macOS 14 and I can easily see a time in the near future where some version of Xcode 26.x requires macOS 26. Dual/triple booting does sound like a way to at least be able to run Test Flight so I can at least do my own verification of functionality before pushing the test build to beta testers. In my specific case, my app is not a game. It's a productivity app. My primary testing concern is ensuring the UI works correctly under different versions of macOS (and iOS for that matter). Being able to do this with VMs would make things SO much easier. One copy of Xcode on the host. One copy of the source code on the host. One build on the host. Then run that one binary (stored on the host) in the different VMs. It would be just like testing iOS apps in different iOS simulators. That's all I want from macOS VMs. Just enough to verify the UI looks and works correctly, just like I do with the iOS version. When I'm satisfied, then I send it off to the beta testers. If macOS 26/Xcode 26 could solve the provisioning issue such that a built app could be run in VMs running macOS 14 and 15 then so many developers would be far more productive. I understand that testing in a VM has limits, just as there are limits in testing an iOS app in iOS simulators. But so much can be tested within those limits. We just need to have the ability do so.

@DTS Engineer What's the point of filing a bug report? Will it actually get fixed? I'm asking a serious question because I've already filed several iOS/iPadOS 26 bug reports related to UISplitViewController and UIKit. Several were reported against beta 1. Those bug reports include trivial sample apps and step-by-step instructions demonstrating the issue. None have been fixed as of iOS/iPadOS 26.0 GM. I also have several outstanding bug reports for broken functionality about UISearchController/UISearchBar under iOS/iPadOS 26. Again, several since beta 1. All include trivial test apps that demonstrate the issue. Again, none have been fixed. All of these outstanding issues are impacting my app. I'm very frustrated and disappointed. I'm sorry but I no longer have the ambition to file more bug reports that will never be fixed. I truly hope Apple gets back to the days of "it just works". That era seems to be lost at the moment. Every year iOS and others are updated with lots of new features and lots of new bugs. I strongly urge Apple to rethink iOS 27. I propose that there be no new features. Instead, go back and fix the countless outstanding issues that fill this forum and Feedback Assistant. Sorry for the rant but I do hope things get better.

@pcfist Thanks for the link. Does that actually work? Some of the posts after the one you linked indicate that it still doesn't work in the end. Yesterday I took the plunge and updated my Mac to macOS 26.0.1 and added a dual boot of macOS 15.7.1. I need to get my app updated for macOS 26 and still support macOS 15 (and 14) and this was the only possible solution for now. Interestingly, both installs of macOS have the same Provisioning UUID. This actually helps some. I can boot into my main system (now macOS 26) and do a development build and test the app with macOS 26. When I want to verify things still work under macOS 15 I can copy the development build to a shared folder, reboot into the other partition with macOS 15, and run the development build from the shared folder. Since both systems have the same Provisioning UUID the app runs without complaint. No need to bother with Test Flight. It's still a giant pain to have to dual boot just to check on a quick change, but at least it can be done and I don't have to push a build to Test Flight and then install from Test Flight. Saves me some time and bandwidth (we don't all have gigabit Internet access - it took me 12 hours to download the 15GB macOS 15 installer!). I still hope Apple can find a solution so we can all use VMs to do builds and testing in a more streamlined fashion.

@vsmedia Be sure that you file a bug report. The more people that let Apple know of this issue, the better chance it will get fixed some day.

@pabugeater You need to file your own bug report using the Feedback Assistant app or website.

See https://developer.apple.com/forums/thread/801977

Set the modalInPresentation property of the view controller you are presenting in a popover to true. This will prevent it from being dismissed automatically when run on macOS via Mac Catalyst. This also prevents the popover from dismissed on an iPad simply by tapping outside of the popover.

You may want to read through this thread: https://developer.apple.com/forums/thread/787500 tl;dr - No

Does anyone know if this problem still exists under macOS 26.1 beta? I have not had a chance to try out the 26.1 beta yet.

Thanks. I’m already making the window key and visible. But that’s not my question. I want this one scene (and its windows) to appear in front of all other scenes (and their windows) in my app. And I want it to stay in front at all times. Even when the user is interacting with any other scene.

FYI - none of these issues have been resolved as of iOS/iPadOS 26.1 beta 2. Dear Apple, please fix all of these scope button issues. They are impacting my app. If you do not intend to fix these then you should mark the APIs as deprecated and suggest an alternate solution.

I just had a chance to test this under iPadOS 26.1 beta 2. Great news - if the primaryBackgroundStyle property of the split view is set to .none then we get back the old style "tile" layout and none of the content of the other columns appear behind the primary column. Thank you. If the primaryBackgroundStyle is set to .sidebar, the primary column is inset a bit as it has been since iPadOS 26.0 (and that's fine for a sidebar). But there is still some unwanted extension of content from the other columns behind the primary column. It's not nearly as bad as iPadOS 26.0. Running the app I used for the screenshot in the first post of this thread now results in just the background color of the selected row appearing on the far left. The section headers do not extend to the far left any more. Here's how it looks now with primaryBackgroundStyle = .none with iPadOS 26.1 beta 2: Here's how it looks now with primaryBackgroundStyle = .sidebar with iPadOS 26.1 beta 2 (note the row selection still extending to the far left): Overall this is a great improvement.

This issue is also affecting existing apps built with Xcode prior to 26 and a base SDK prior to 26 but being run on macOS 26. So clearly it's a framework issue in macOS 26 that is affecting an app no matter how/when it was built. It just needs to be an app using "Scaled to Match iPad". I really hope Apple gets this resolved in macOS 26.1 (along with half a dozen other critical functionality bugs that I've reported and still are not fixed).