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

@BenjaminApple There are three primary use cases for most macOS developers running a beta OS in a virtual machine (such as macOS Ventura in UTM): To download their existing apps from the Mac App Store to verify that everything works correctly on the new OS. An Apple ID is needed to download from the Mac App Store. To build and debug their apps using Xcode. An Apple ID is needed to setup an account in Xcode so automatic code signing can be used. To test apps that use iCloud. An Apple ID is needed to access iCloud in System Settings. -ch

Returning false for the beginning of the interaction does disable Scribble, but does not prevent the widget from appearing. Setting the inputView to nil has no effect, the widget still appears instead of the keyboard. Since there is no public way to get the user's preferred keyboard view, I don't see how this approach can work. -ch

Let's get a little bananas here: https://stackoverflow.com/questions/57929968/getting-and-setting-the-position-of-content-in-a-swiftui-scrollview :fingers-crossed: -ch

Yay!

If you're confused by this post, replace the first star with N. Then the second one with A. Then the third with S. Then, you guessed it, the fourth with T. And finally, Y. –ch