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.

The issue is setting .preferredColorScheme on the sheet. A nil value (for system appearance) does nothing. A full working solution without using UIKit can be found here: https://gist.github.com/chockenberry/a2a23a12604e333b1c2a8b71e7a24155 Apple folks: FB15105356

The new technique is to enable an inspectable property on the JSContext and WKWebView. https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps/ -ch