AppleID Login failing in virtualized OS

Logging in with my Apple ID anywhere in the system (feedback assistant, Xcode, iCloud, etc.) fails when running under virtualization. Is this a known 'issue'? (networking in general is working fine)

Answered by DTS Engineer in 790410022

Apple just started seeding macOS 15 beta, where the Virtualization framework supports iCloud logins for macOS 15 guests. For the details, see Using iCloud with macOS virtual machines.

IMPORTANT This requires macOS 15 as both the guest and the host.

Share and Enjoy

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

It is a known limitation.

The virtual Mac cannot authenticate with the server in the way the physical Mac can.

We are really interested to learn about which use cases you are interested in. Different services have different security requirements and understanding the needs is useful for us. Could you please file a feature request in Feedback Assistant?

@BenjaminApple There are three primary use cases for most macOS developers running a beta OS in a virtual machine (such as macOS Ventura in UTM):

  1. To download their existing apps from the Mac App Store to verify that everything works correctly on the new OS. An Apple ID is needed to download from the Mac App Store.

  2. To build and debug their apps using Xcode. An Apple ID is needed to setup an account in Xcode so automatic code signing can be used.

  3. To test apps that use iCloud. An Apple ID is needed to access iCloud in System Settings.

-ch

21

@BenjaminApple To add to what @chockenberry listed - while it's easy enough to create a new APFS volume and dual-boot into Ventura, some of the key advantages that I see of using a VM are:

  • Easily create / delete instances without the full installation process. A template image can be generated once and easily copied repeatedly for new tests.
  • VMs can be configured with specific memory sizes and CPU core counts, which is hard and/or impossible to duplicate on the bare-metal host without multiple testing computers
  • Beta development environments can be worked on in isolation while a developer's day-to-day workflow can continue on the host running a stable, released OS.
  • Expanding on the item above, corporate security policies may not allow running pre-release software on a network-exposed host. Running a beta OS in a VM with networking isolated allows the developer to continue to use collaboration software, etc. on the host without dual-booting back and forth or using a second system.
13

All of the above. Rebooting my primary machine to test a beta is not feasible, I am regularly in video calls throughout the day, and I would have to disrupt them every time I reboot. The beta is still not stable enough for me to consider running it for regular use. I currently have no less than 5 outstanding feedback issues filed, none of which have been answered yet. One of them is the ability to actually respond to Feedback questions from Apple, which is currently broken. The "This is fixed" / "This is not fixed" bubble prompts do not appear in the dialog, so it is impossible to send a response to Apple.

Incidentally, it's also not possible to maintain a beta install on a primary development machine if you develop for the App Store, as the beta does not support stable Xcode, and the beta, like all betas in the past, cannot be used to publish to the App Store, unless you use Xcode Cloud to build using a stable version. And I find I cannot use Xcode Cloud, because it messes with my app's Info.plist bundle version in unpredictable ways. I cannot get it to build consistent versioning. I use a template Info.plist and generate the version number from the Git repository at build time, and Xcode Cloud ignores this and stamps the Info.plist with its own decided version string, even one which is incompatible with the App Store, as it contains letters. (It uses the first five of the Git hash as the version string, ignoring my chosen version template of commit number since a specific tag.)

I solved my Xcode Cloud issue, but dual booting is not really that useful of an option. I have the 256GB storage option, which is criminally small.

As per the other commenters above, the principal reason for running macOS in virtualized containers is to bypass the need to dual boot a machine to get access to a beta OS for testing software, which as a workflow is cumbersome and in reality completely impractical when also needing to be joining video conferences and conforming to corporate IT security policies.

Please provide us with a solution for logging in to the App Store / other iCloud services from macOS VMs on Apple Silicon.

Sys admins need this as well. We're a Managed Services Provider supporting mixed platform environments (primarily Windows with a subset of Mac devices). The ability to spin up a clean VM and use for generating either internal use or end user facing documentation is huge. From a support standpoint, it would also be extremely beneficial to be able to spin up a clean VM, install a specific application and end user is using to attempt to replicate an issue they're having. These are two primary use cases where we leverage Windows VMs all the time - spin up a clean install, use it for a few hours or a few days to get what we need then just **** it away. But if we can't access the AppStore from within the VM, it drastically limits what we can do with the VM. I personally cannot imagine why not having 100% feature parity between a physical installation and a virtual machine would be considered acceptable - but that's just me :)

@BenjaminApple, you asked "Could you please file a feature request in Feedback Assistant?"

YES, I'd love to! But I can't sign in into Feedback Assistant because my Apple ID is not working on a VM.

This needs to be supported - it's quite pointless to have macOS support in a VM if it's going to end up neutered on its most basic functionality.

+1 for this, I really need this feature, it would speed up so much testing.

+1 for this, I really need this feature, it would speed up so much testing. 

+1 for this, same problem with the production released Ventura, not beta. Virtualisation was a big part of Apple's announcements this year, so it is no longer an edge case but a core feature. Devs need to have multiple versions of MacOS for testing, and this now includes Ventura.

I came here trying to figure out how to sign into the App Store in order to install XCode. It turns out all the dev tools can also be downloaded directly from https://developer.apple.com/download/all/ instead of the App Store, which gets around the need to sign into the App store for that particular purpose.

+1 need Apple ID to work inside a macOS guest VM. Use case is running dual work & personal macOS installs. Ideally, one of these could be a VM for convenient switching without having to reboot. This requires the macOS guest VM to support Apple ID logins to download apps only available in the App Store.

AppleID Login failing in virtualized OS
 
 
Q