Building macOS apps with Xcode 26 on macOS 26 VM

Code Signing Certificates, Identifiers & Profiles
chockenberry OP
Created Jun ’25
Replies 45
Boosts 11
Views 7.4k
Participants 16

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 863361022

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.

Replies  45
Boosts  11
Views  7.4k
Participants  16
DTS Engineer OP
Apple
Jul ’25

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"

1
GeeBee2 OP
Aug ’25

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

3
chockenberry OP
Aug ’25

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

0
DTS Engineer OP
Apple
Aug ’25

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 (-:

0
RickMaddy OP
Aug ’25

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.

0
chockenberry OP
Aug ’25

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.

1
chockenberry OP
Sep ’25

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

0
chockenberry OP
Sep ’25

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

0
jckbiggs OP
Sep ’25

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.

1
chockenberry OP
Sep ’25

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

1
RickMaddy OP
Sep ’25

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?

0
marco.masser OP
Sep ’25

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.

0
DTS Engineer OP
Apple
Sep ’25
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.

0
RickMaddy OP
Sep ’25

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.

2
pcfist OP
Oct ’25

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

0
Building macOS apps with Xcode 26 on macOS 26 VM
First post date Last post date
 
 
Q