Now that this is mostly working, I've come across a new issue I'm wondering if anyone else is seeing. Using UTM version 4.7.4 on a macOS 26.0.1 host, I am setting up a macOS 26.1 beta 3 guest. I am unable to log into my Apple ID in the macOS 26.1 beta host. This happened with beta 1 and now with beta 3. This is not just the normal limitations of logging into an Apple ID in a macOS VM. With macOS 26.1 beta, you can't login at all. This means no iCloud access. This means you can't even update to the next beta since you need iCloud access for the Software Update screen to even offer the Beta Software update option. I also have a macOS 15.7.1 VM and a maCOS 14.6.1 VM on this same host and they both let me login just fine (with the usual limitations). I filed bug FB20668616 but I'm curious if anyone has seen this. One step forward, one step back.

This issue still exists in macOS 26.1 beta 3.

Still unresolved with iPadOS 26.1 beta 3.

All of these issues still exist with iPadOS 26.1 beta 3.

Like most app metadata in App Store Connect, screenshots can only be updated while you are preparing an app update. So yes, you need to create a new release (and upload a new binary) and update its screenshots before you submit it for review.

Yeah! It's working! I have a macOS 26.0 host. In UTM I have a macOS 15.7 guest with a Provisioning UUID that has never been added as a device in the developer portal. I also have a macOS 14.6.1 guest that has already been added to the developer portal. In my developer account I added a new device with the new guest VM's UUID. It's the longer style with lowercase hex digits. I then edited my existing manual provisioning profile with the new device. I also added the older existing device that has the short, uppercase style UUID. In Xcode (26.1 beta 2) I changed my app's signing from automatic to manual and referenced the updated provisioning profile. I built the app and copied the new app to a share I use for the VMs. I ran the VMs and tried to run the updated app. It failed. I missed one step that maybe some others might miss. In Xcode, go to Settings, Apple Accounts. Select your account. Then select your team. Then click on "Download Manual Profiles". Once I did that, I rebuilt the app with the now properly updated provisioning profile and recopied the app to the share. And now the app runs in both guest VMs! Key steps for those that are not starting from scratch: Update your provisioning profile in your developer account. You may need to remove devices and then re-add them. Existing devices might only work if the case of the provisioning UUID on the device matches the case shown in your developer account. Be sure you are using the updated provisioning profile when you build. Update via Xcode's Settings screen before building the app. Thanks to those that made this happen.

@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