Building macOS apps with Xcode 26 on macOS 26 VM

I'm trying to setup a macOS 26 build environment in a VM (using UTM and the virtualization framework Apple provides).

I have Xcode 26 installed and have logged into my Apple ID and verified that the team and other configuration looks fine in Xcode settings.

When trying to build the macOS app, I see errors saying the VM's device ID has not been registered. I have confirmed that the device ID is registered both in the Provisioning portal AND the downloaded .provisionprofiles (in Library > Developer > Xcode > UserData).

This problem appears on multiple targets (e.g. the main app and extensions).

If I try to manually provision the app, using the Provisioning portal, I can build the product, but it will not launch because of Gatekeeper issues.

Finally, signing to run locally doesn't work either. As the app launches, frameworks refuse to load because Team IDs don't match. With ad hoc provisioning, there are no Team IDs.

I've come to the conclusion that this just isn't possible.

Which is a shame because I need to support products with a build environment on macOS 15 and cannot move over to macOS 26 yet. I suspect many developers outside of Apple are in a similar position.

Answered by DTS Engineer in 843094022

There’s a bunch of backstory here. Let me recap…

In the beginning, Apple silicon VMs did not support Apple Accounts (or Apple IDs as they were known then). We fixed that in macOS 15, but only for macOS 15 guests running in VMs created on macOS 15. See AppleID Login failing in virtualized OS. Notably, this involved a significant change to the underlying security infrastructure in the guest.

Unfortunately this change revealed an Xcode specific problem, where you weren’t able to sign in to your developer account with Xcode. We fixed that with a Developer website change back in Feb 2025. See Xcode 16.1 can't load the Account information in VM.

However, that’s revealed another problem: The new VMs used a new provisioning UDID format, and it wasn’t possible to create a provisioning profile that included such UDIDs. See "Provisioning profile does not allow this device" on Sequoia 15.2 VM. We fixed that problem with a Developer website change in Apr 2025.

However, that revealed another problem, where the guest wasn’t accepting what would otherwise be considered a valid profile (r. 149209127).

That problem will need to be fixed in the OS itself. I just checked on the bug and it’s definitely with the right people, but that’s all I can say right now.

So, where does this leave you. The following things work:

  • You can run Xcode in a VM and use it to build and run programs that don’t require a provisioning profile.

  • You can create a VM on macOS 14, which will have a UDID in the original format, and use that to test programs that do require a provisioning profile.

However, you can’t combine these two things. The same feature that allows you to add your Apple Account to Xcode prevents you from creating a provisioning profile for the guest.

I’m hoping we fix this sooner rather than later but, again, I can’t offer any concrete predictions as to when that’ll be.

Share and Enjoy

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

@pcfist Thanks for the link. Does that actually work? Some of the posts after the one you linked indicate that it still doesn't work in the end.

Yesterday I took the plunge and updated my Mac to macOS 26.0.1 and added a dual boot of macOS 15.7.1. I need to get my app updated for macOS 26 and still support macOS 15 (and 14) and this was the only possible solution for now. Interestingly, both installs of macOS have the same Provisioning UUID. This actually helps some. I can boot into my main system (now macOS 26) and do a development build and test the app with macOS 26. When I want to verify things still work under macOS 15 I can copy the development build to a shared folder, reboot into the other partition with macOS 15, and run the development build from the shared folder. Since both systems have the same Provisioning UUID the app runs without complaint. No need to bother with Test Flight. It's still a giant pain to have to dual boot just to check on a quick change, but at least it can be done and I don't have to push a build to Test Flight and then install from Test Flight. Saves me some time and bandwidth (we don't all have gigabit Internet access - it took me 12 hours to download the 15GB macOS 15 installer!).

I still hope Apple can find a solution so we can all use VMs to do builds and testing in a more streamlined fashion.

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

not being passive aggressive here

Understood.

I’m about to head out for a few weeks, and I won’t have a chance to post updates here in the interim. So it’s definitely worth continuing to test.

Keep in mind my earlier comment:

It’s possible that this might end up being a Developer website change.

That’s looking more and more likely. And if it is such a change, that will roll out independently of the macOS 26.x beta cycle. We don’t have a standard way of notifying folks of Developer website changes, but if you keep testing on the betas it’s likely you’ll eventually notice it (-:

Share and Enjoy

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

Hi @RickMaddy, just tried the update method yesterday and now I can confirm it works as described. Installed macOS 14.6.1 to a fresh VM, then upgraded to Tahoe via System Settings. As one would expect, the UDID remained unchanged after the upgrade, which seems essential for the developer signature to work correctly.

My developer-signed app built on the host machine starts without issues in the guest running macOS 16 (after adding the UDID in the Developer portal).

Please see if it works for you—still a bit cumbersome, but looks much more convenient compared to the dual-boot scheme.

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

Just received a reply on my feedback (FB19620814) regarding this issue:

Please know that this issue should now be addressed. Please let us know if you're still encountering the problem.

I haven’t had time to verify this on my own yet, however. Seems like it’s worth retesting.

I have re-generated my Provisioning Profiles after your message @kthchew - just to make sure I got the updates on the website side - but on Tahoe 26.0 this is still not working. Apps with the PP do not start as before, manually trying to install the Provisioning Profile says the "Provisioning profile does not allow this device" on the VM.

I can't speak for Tahoe 26.1 beta myself, but this is definitely not fixed.

I tested it in Xcode 26.1 Beta 2 on macOS 26.1 Beta 2 without success. I still get the same error message.

I was able to test on my own, and in my tests it seems like provisioning profiles now work in the VM. But it took some extra work than just recreating the provisioning profile. My host is on macOS 15.7.1 (24G231).


tl;dr try making a brand new VM such that it has a new provisioning UDID and try again


My "success" case was as follows:

  1. I had an older "clean install" VM on macOS 15.7, but it does have the newer provisioning UDID style. I did not add it to my account until just now, however.
  2. I manually added the provisioning UDID to my devices list on the developer website. Now, the new device that I just registered on the website has an identifier with lowercase letters (e.g. c28165661eb...) (before, it looks like it automatically set it to uppercase).
  3. I recreated the provisioning profile, and built an app using Xcode on my host.
  4. I transferred the built app into the VM via a shared folder.
  5. I opened the app, and the app extension worked successfully (in my case, my app itself doesn't use a provisioning profile, but its app extension does).

The "failed" case (where I tried just recreating the provisioning profile) was as follows:

  1. I had a VM on macOS 26.1 beta 2, where I had already added the provisioning UDID on the site before. Under my account, any letters in the UDID are shown as uppercase (e.g. E784ACDA...)
  2. Since the device was already on my account, I just regenerated a provisioning profile and rebuilt my app.

This did not work.

My assumption is that the OS version here is not what matters. Perhaps the difference is the capitalization in the UDID on the website, and if so then maybe that's how they were able to deploy a fix via the website. Unfortunately, you don't seem to be able to change the capitalization of the UDID if it is already registered. If you disable the device and attempt to add it again manually, it will see that the device is "already" there with the uppercase capitalization and simply re-enable the faulty one.

I would assume that you can recreate a new VM from scratch, such that it has a brand new provisioning UDID, then add it to your account. That seems like it should work.

Also note that I did not test building with Xcode directly in the new VM to register the VM with my account; I added it manually on the website. I would hope that Xcode handles this properly, but if it still doesn't work, perhaps try manually registering the device on the website.


Edit 2: I just ran another test where I allowed Xcode running in the VM to automatically handle the new device registration instead of doing that manually on the site, and the extension requiring a profile ran, with correct capitalization of the UDID appearing on the website. This was on a macOS 26.1 beta 2 VM.

So then it seems like this should "just work" on a VM with a UDID that hasn't been registered to your account before.


Edit: Also, if you don't want to make a whole new VM from scratch, you can do the following to cause the provisioning UDID to change:

  1. Make a clone of your VM.
  2. Run the clone.
  3. While the cloned VM is still running, run the original VM simultaneously.

One of the VMs will have a new provisioning UDID. Use the VM with the new provisioning UDID. You can then delete the VM that has the old provisioning UDID, if you want.

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:

  1. 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.
  2. 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.

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

Building macOS apps with Xcode 26 on macOS 26 VM
 
 
Q