@Matt522 Make sure you file a bug report using Feedback Assistant. Apple needs to know that this affects people's apps. Be sure your bug report includes a simple app that demonstrates the issue.

Change your code in viewDidLoad to: var cfg = PagesInterface.configuration cfg?.cornerStyle = .fixed // Or change the button's "Corner Style" to "Fixed" in the storyboard cfg?.background.cornerRadius = 0 PagesInterface.configuration = cfg With a style of fixed the button's corner radius comes from the background's cornerRadius property. Please also note that it is common practice to name variables starting with lowercase letters. Your PagesInterface variable should be named pagesInterface. Uppercase names are usually used for class/struct/enum names.

@pcfist Thanks for the confirmation. I'll give it a try when I get a chance. Unfortunately I am spending most of my time finding and reporting macOS/iPadOS/iOS 26 bugs that are impacting my app. Then I waste time trying to find work arounds since Apple isn't fixing any of the issues.

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

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.

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.

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.

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.

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

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.