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.

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

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

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

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

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

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.

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?

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.

@philmctim FYI - Xcode 26.0 runs on macOS 15.6. No need to install macOS 26 just to use Xcode 26. At least for now. Though if you want to use the AI stuff in Xcode 26 you apparently do need macOS 26.

See the following post for the answer: https://developer.apple.com/forums/thread/788843 Be sure to read through to the last answer.

This issue still exists with the release version of iPadOS 26.0 (23A341). FB20199167 FB19771313

This is still an issue with iOS 26. Tested on an iPad running iPadOS 26.0 (23A341). FB20199308 FB17888632

I don’t have access to another computer. Xcode downloads and installs the aar file. There must be a way to trick Xcode into thinking it downloaded the file itself and then completing the installation. I would think it’s just a matter of putting the aar file in the right directory.

Thank you. Setting preferredPlacement to fixed was the missing piece. I already had allowsHiding set to false and I’m not using any tab groups. The Edit button no longer appears in the sidebar. But I have discovered an iOS 26 (and iOS 18) bug in the process. I need to file a bug report but here’s the issue. I present the tab bar controller as a modal view controller on an iPad. If I resize the app window from full screen to a size that is horizontally compact while the tab bar controller is in view, the tab bar controller of course changes from showing a sidebar to showing an old style tab bar on the bottom with a More tab. Selecting the More tab now shows an Edit button. But only in this case. If the tab bar controller is presented after the app window is made horizontally compact, then the More tab does not show the Edit button.