Building macOS apps with Xcode 26 on macOS 26 VM

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.

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

Hooray! Glad to see it's working now.

Does this only work when using a personal team?

I've just tried a near-identical setup - Virtual Buddy 2.1, Xcode 26.5 RC, Tahoe 26.5 beta (not the latest).

I'm still getting "Device My Mac is not registered to your team..." in XC on the VM. It says I do not have permission to register them, but I'm signing in with a developer account that has admin rights for the team in question. I'm signing in to the VM and Xcode with the same Apple ID fwiw.

The app I'm testing uses iCloud and so I can't test it using a personal team.

I’ve always tested this with a Personal Team because my Individual team is from work and that’s problematic for this sort of test [1].

From your post it wasn’t clear whether you tried this with a Personal Team or not? If not, please do. That’ll let us distinguish between general borkage and a Personal Team / Individual team discrepancy.

The app I'm testing uses iCloud and so I can't test it using a personal team.

OK, but you can still run this test by creating a new test project that’s not tied to Xcode Cloud. Just make sure you add a restricted entitlement to the project so that you exercise the provisioning profile path. I like the Maps capability for this, because it’s one of the few capabilities that’s available to a Personal Team and unequivocally requires a restricted entitlement.

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

[1] While my work Individual team is virtually identical to an Individual team used by third-party developers, the one place it differs is authentication.