My confusion about automatic safe area insets was due to a single dropdown in a collection view's storyboard: The storyboard was using "Content Inset", which I'm thinking might be a default value. Everything works fine after changing the dropdown to "Safe Area" (and a sectionInsetReference="safeArea" attribute is added to the storyboard object graph). This setting also led me to believe that table views didn't handle the situation automatically (they do). It seems to me that "Safe Area" is a better default these days - there are probably compatibility issues I'm not aware of, but folks moving their storyboards to the Duo will likely hit this issue and be confused just like I was.

I think I might have answered my own question. When I encountered a collection view in my view hierarchy, I realized that adding a container view was intractable: the only views to modify are cells. It then occurred to me that I really want to adjust content inset, so I tried this: scrollingView.contentInset = view.safeAreaInsets That leaves the scroll indicators at the view edges and gets my content inside the safe area. Again, I'd like confirmation that this is the correct approach. And now I'm also wondering why this isn't the default behavior or something that can be modified in a storyboard. Any additional information would be greatly appreciated.

For everyone else following along, here is a ZIP file that contains the project: https://files.iconfactory.net/craig/bugs/Resizer.zip And the steps to reproduce the issue: Open the attached project (Resizer.zip) in Xcode 27.0 beta 2 (27A5209h) Build & run the project in Device Hub Version 27.0 (244.2.3) using an iPhone 17 device Enter resize mode Resize the interface to 1280 x 960 Expected results: The NSAssert at line 31 or line 71 should fire because the horizontal size class is larger than compact. Actual results: The NSAssert never fires because the horizontal size class is always compact. Note: This behavior does not occur on the iPad: the asserts fire because the size class changes as the window is resized.

I just submitted a simple project with FB23422375 that demonstrates the issue.

Working for me, too! This is really great news - huge thanks to everyone who helped make it happen! We should let @DTS Engineer head out for a few weeks more often! -ch

Still get a "Runningboard has returned error 5" with Tahoe 26.1 Beta (25B5042k) and Xcode 26.1 beta 2 (17B5035f). (Note to @DTS Engineer and others - not being passive aggressive here - just want others to know if it's working in each new release.)

Still get a "Runningboard has returned error 5" with Tahoe 26.1 Beta (25B5042k) and Xcode 26.1 beta (17B5025f).

Still get a "Runningboard has returned error 5" with Tahoe 26.0 RC (25A353) and Xcode 26.0 RC (17A321).

Still get a "Runningboard has returned error 5" with Tahoe 26.0 Beta 9 (25A5351b) and Xcode 26.0 beta 7 (17A5305k).

Just tested with most recent Tahoe 26.0 Beta (25A5349a) and Xcode 26.0 beta 7 (17A5305k). Still get a "Runningboard has returned error 5." @DTS Engineer Let me know where I should check in the provisioning portal if/when it changes.

Just tested with most recent Tahoe 26.0 Beta (25A5349a) and Xcode 26.0 beta 6 (17A5305f). Still get a "Runningboard has returned error 5."

My signing certificate is indeed fine: I'm wondering if having multiple WWDR and Developer ID certificates could be a problem.

After some rebooting of the VM and restarting Xcode, I think the device provisioning was recognized. At least I was able to build and sign a sample app. Running it led to: The app is just the standard macOS SwiftUI template (with "Hello world" in the middle of a window). I added the iCloud key/value store capability to the template. It's hard to tell what runningboardd is doing in the Console (it spews A LOT of information). The best indicator is from Apparency https://mothersruin.com/software/Apparency/: The signing signature (from what looks like a valid certificate) is not accepted by Gatekeeper: I feel like we're really close here...

The failure is also characterized by an "Update Signing" project build task that never completes. I see the UUID and name of the device in the JSON payload of that task. The JSON payload is generated by IDEProvisioningRepair(ProjectName) from an endpoint on developerservices2.apple.com/services/v1/certificate

If you build a minimal app using your development team and an automatically generated provisioning profile, it works fine. As soon as I add the iCloud capability, I start to see the "Device XXXX isn't registered in your developer account" error.