Building macOS apps with Xcode 26 on macOS 26 VM

I did an end-to-end test of this earlier in the week. Sadly, the news isn’t good. The Xcode side of this continues to work but the guest still won’t accept the profile. I continue to work with the virtualisation folks to see if we can get this sorted.

Oh, and just for the record, my test was macOS 26.0b4 host and guest, building with Xcode 26.0b4 on the guest.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The problem persists on macOS 26 Beta 5 / Xcode 26 B5 in a VM running on macOS 15.6 with Virtualization tools beta 2.

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

Yep. That gels with my view of the Land Bug Standing™ [1] (r. 149209127).

One small update on that front. Earlier I wrote:

That problem will need to be fixed in the OS itself.

I’m less certain about that now. It’s possible that this might end up being a Developer website change.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I hope (-:

Getting this fixed now is almost pointless. In two weeks the GM for macOS 26 likely will be out. We needed this fixed months ago so we could test the beta macOS while using a stable macOS.

Maybe we’ll get lucky and by next June we’ll be able to test macOS 27 beta using macOS 26.6.3 and Xcode 26.4.

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.

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

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

I reported this same issue back in January, we haven't been able to run our automated tests in our build infrastructure for 9 months now.

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

Now that macOS 26 GM is out, and even 26.1 beta is out, where does this all stand? More specifically, does anyone know if using macOS 26 as the host, can we create a macOS 15 VM guest all while allowing us to build and test our apps on both macOS 26 and 15?

I still have macOS 15.6 on my only Mac. My app supports macOS 14-26 (well, will support macOS 26 when I can actually test with it). But I have no way to test it in any of the VMs since my app needs a working provisioning profile. Even in a macOS 15 guest on my macOS 15 host, I can't even log into TestFlight to test my app. Will updating to a macOS 26 host allow the macOS 15 guest to at least use TestFlight to download the app for testing?

In other words, is there any viable way for a solo developer with one Mac to develop and test a macOS app that runs on more than one version of macOS?

In other words, is there any viable way for a solo developer with one Mac to develop and test a macOS app that runs on more than one version of macOS?

You can always install another OS on a separate volume and boot from that for building and/or testing.

where does this all stand?

For a summary of the current state of the issues being discussed in this thread, see my 27 Aug 2025 reply. However, your questions extend beyond that, so let’s dig in.

is there any viable way for a solo developer with one Mac to develop and test a macOS app that runs on more than one version of macOS?

Yes. As marco.masser suggested, you can boot your Mac into older versions of macOS and test there.

I want to stress that, while VMs are super useful, they are not a substitute for testing on real hardware [1]. VMs have limits:

• Some are bugs, as we’ve been discussing on this thread.
• Some of them are absent features. Of these, the lack of TestFlight support is the most critical. I’ll come back to that below.
• Some of them are just fundamental to VMs. For example, if you’re building a graphics-heavy app, like a game, you need to test on a wide range of real GPUs.

Now let’s come back to TestFlight.

The Apple Account support in Apple silicon VM’s has a number of limitations. See the Use iCloud on a virtual machine article from Apple Support. Under iCloud features not available on a virtual machine they wrote:

• Apple Media Services, such as apps, movies, music, books, and more

In this case, “apps” includes App Store and TestFlight. You won’t be able to test via TestFlight in a VM.

So, if you absolutely must test using TestFlight, VMs are not the answer regardless of what’s happening with the issues being discussed on this thread.

One alternative is to export a Developer ID signed build of your app and test with that. However, that has its own limitations. Specifically, some features are not available to Developer ID apps. The one that folks most commonly bump in to is Sign in with Apple.

I also want to talk about CPU architecture. If you’re app supports Intel Macs then you need to test it on an Intel Mac. Rosetta is fine for day-to-day testing but your customers won’t be using Rosetta.

And if you have an Intel Mac lying around, it can help with the issues being discussed on this thread. The focus of this thread is Apple silicon. Intel virtualisation solutions use very different code paths and aren’t subject to the limitations being discussed here.

Finally, as a solo developer you’re never going to be able to set up adequate testing in-house. There are way too many combinations of macOS and Mac hardware, and that’s before you even worry about environmental issues like networking. You’ll need to recruit a good selection of beta testers. Hence, all of the above is about doing the initial basic testing of your app before you release it to your beta testers.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Unless you happen to be building a product that customers deploy to a VM. That’s pretty common the server side of things, with containers and what not.

Dual booting (triple in my case - 14/15/26) is not a viable option for Xcode development and testing of an app because different versions of macOS support different versions of Xcode. While Xcode 26.0.1 currently runs on macOS 26 and macOS 15.6, it certainly can't be run on macOS 14 and I can easily see a time in the near future where some version of Xcode 26.x requires macOS 26.

Dual/triple booting does sound like a way to at least be able to run Test Flight so I can at least do my own verification of functionality before pushing the test build to beta testers.

In my specific case, my app is not a game. It's a productivity app. My primary testing concern is ensuring the UI works correctly under different versions of macOS (and iOS for that matter).

Being able to do this with VMs would make things SO much easier. One copy of Xcode on the host. One copy of the source code on the host. One build on the host. Then run that one binary (stored on the host) in the different VMs. It would be just like testing iOS apps in different iOS simulators. That's all I want from macOS VMs. Just enough to verify the UI looks and works correctly, just like I do with the iOS version. When I'm satisfied, then I send it off to the beta testers.

If macOS 26/Xcode 26 could solve the provisioning issue such that a built app could be run in VMs running macOS 14 and 15 then so many developers would be far more productive.

I understand that testing in a VM has limits, just as there are limits in testing an iOS app in iOS simulators. But so much can be tested within those limits. We just need to have the ability do so.

@RickMaddy Possible workaround mentioned in another thread is to create a VM with older operating system (macOS 14 Sonoma or earlier) and then upgrade the guest to a newer version. It ensures the VM has an old format UDID which will allow the provisioning profile to work correctly. May be worth trying until there is a proper fix.