Building macOS apps with Xcode 26 on macOS 26 VM

@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

Now that this is mostly working, I've come across a new issue I'm wondering if anyone else is seeing.

Using UTM version 4.7.4 on a macOS 26.0.1 host, I am setting up a macOS 26.1 beta 3 guest. I am unable to log into my Apple ID in the macOS 26.1 beta host. This happened with beta 1 and now with beta 3.

This is not just the normal limitations of logging into an Apple ID in a macOS VM. With macOS 26.1 beta, you can't login at all. This means no iCloud access. This means you can't even update to the next beta since you need iCloud access for the Software Update screen to even offer the Beta Software update option.

I also have a macOS 15.7.1 VM and a maCOS 14.6.1 VM on this same host and they both let me login just fine (with the usual limitations).

I filed bug FB20668616 but I'm curious if anyone has seen this.

One step forward, one step back.

@RickMaddy I think that might be a little out of scope for this thread. But in any case, I was able to update my macOS 26.1b2 VM to 26.1b3 via my logged-in Apple Account, so I don't think it's universally broken. Although my host is still on Sequoia 15.7.1.

The closest thing I've experienced to what you're describing is an issue that I've seen for a while where logging in with an Apple Account hasn't been working for me if I have physical security keys enabled on my account for 2FA (FB19614234). Unfortunately if you're in this situation I don't know of any workaround other than removing all the security keys (and even if you re-enable them after logging in with the VM, eventually the VM will start complaining with pop-ups asking you to login again, although beta updates will still work despite this). This isn't new to 26.1, though. If this isn't the issue you're experiencing you might find better luck creating a new thread since I don't think many people with similar issues are going to find this reply buried in this thread.

So, the tl;dr here is that this issue is now resolved. There may be other outstanding issues, but you can now:

• On a macOS 15 or later host, install macOS 15 or later in a VM.
• On the guest, log in using an Apple Account in System Settings.
• And install Xcode.
• And add your Apple Account to Xcode.
• And then build and run a Mac app.
• Even if it uses a restricted entitlement.

If you’re interested in how I tested the above, I’ve included a summary at the end of this post.

If you’re encountering other issues, please start a new thread with the details. This thread is already long enough |-:

If you’re interested in the history, I have a summary of that in this post. That was from 13 Jun 2025. Since then there’s been one critical change, namely that on 9 Oct 2025 we rolled out a Developer website update that fixes the provisioning UDID issue (r. 149209127).

And on that note, I think I can finally put this issue to bed.

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

To test this:

1. I ran Virtual Buddy 2.0.1 on macOS 15.7.1.
2. Using that, I created a new VM running macOS 15.6.2.
3. In the guest, I installed Xcode 26.0.
4. I logged into System Settings using my test account. This has two-factor authentication enabled.
5. I then logged into Xcode > Apple Accounts with the same account. This is not a member of any paid team, so I ended up using a Personal Team.
6. I created a new app from the macOS > App template.
7. In Signing & Capabilities, I confirmed that automatic code signing was enabled and my Personal Team was selected in the Team popup.
8. Still in Signing & Capabilities, I added the Maps capability. I chose this because it’s tied to a restricted entitlement [1] but is available to a Personal Team. See Developer Account Help > Reference > Supported capabilities (macOS).
9. I chose Product > Run. The app built and ran successfully.
10. I then dumped various things to confirm that they’re working as I expected.

First I dumped the entitlements claimed by the app:

% codesign -d --entitlements - Test20251024.app                                       
…
[Dict]
    …
	[Key] com.apple.developer.maps
	[Value]
		[Bool] true
    …

The Maps entitlement is there. Yay! I then dumped the profile:

% security cms -D -i Test20251024.app/Contents/embedded.provisionprofile | plutil -p -
{
  …
  "Entitlements" => {
    …
    "com.apple.developer.maps" => 1
    …
  }
  …
  "ProvisionedDevices" => [
    0 => "2e876f5c949604b331a83f7c41eaa8c6c150ae86"
  ]
  …
}

That authorises the use of the Maps entitlement. Yay!

I then dumped the provisioning UDID of the (virtual) Mac:

% system_profiler SPHardwareDataType
Hardware:

    Hardware Overview:

      …
      Provisioning UDID: 2e876f5c949604b331a83f7c41eaa8c6c150ae86
      …

This matches the value in the profile. Yay!

[1] Most of the other capabilities are tied to _validation-required entitlements, which is a subtlety I discuss in the Entitlements-Validated Flag section of App Groups: macOS vs iOS: Working Towards Harmony.