AppleID Login failing in virtualized OS

OK, so, lemme start with some facts:

• Apple silicon macOS virtual machine don’t support Apple ID logins.

• This has been true since the Virtualization framework was introduced in macOS 11.

• It’s still true in macOS 14 (currently in beta).

• This means that a number of important workflows don’t work in such VMs.

• Apple has made no official announcement about whether this will change in the future.

Normally when you bump into a limitation like this I recommend that you file an enhancement request [1] describing how it’s causing problems. In this case that’s not necessary. We’ve had plenty of bugs about this already |-:

I will update this post if this situation changes in the future.

There’s been a lot of speculation as to why things are this way. I can’t answer Why? questions in general [2], and I’m certainly not going to comment on speculation. I will point out, however, that the bug reports filed about this have not been returned as behaves correctly.

I thought long and hard about the final disposition of this thread. I was quite tempted to lock it, because the signal-to-noise ratio is quite poor. However, I eventually decided to leave it open so you folks can chat amongst yourselves. Be aware, however, that I’ve unsubscribed, and thus I won’t see any of your posts.

If you have a technical question about Virtualization framework, please do start a new thread here on DevForums, tagging it with the Virtualization keyword. Before you do that, however, please review tips 1 through 3 in Quinn’s Top Ten DevForums Tips.

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

[1] AKA a suggestion in Feedback Assistant. See Bug Reporting: How and Why? for more background on Apple’s bug reporting process.

[2] See tip 3 in Quinn’s Top Ten DevForums Tips.

+1, please fix! I am trying to use these VMs for testing MDM deployments and many features are dependent on signing in with Apple ID

+1 on Fix.

If we run in x86_64 using Rosetta, it works?

Just to add to the use cases - the upgrade to Sonoma broke one of my critical apps - like others here, I've invested heavily in a high spec machine for the purpose of virtualisation, and not being able to run an older version of MacOS is bonkers (aside from the time I just wasted wondering what the heck was going on !) so +1 for this feature. I'm left hoping that my vendor fixes the issue soon otherwise I have to downgrade, and that's never fun :-/

Oh wow, just setting up my new mac with bumped up specs in order to run virtual machine dev environments and hit the same limitation as everyone else here. :-( What a HUGE disappointment and failure. I'm flabbergasted apple thought this intentional limitation was acceptable. I hope they reverse course and lift this show stopping restriction.

I just stumbled onto this issue. This is horrific and breaks one of the main reasons I updated. This is a really dumb archaic rule and needs to be changed to enable vm's to sign into icloud.

I'd love it if Apple would have this fixed soon given that it presumably has been an issue for 2-3 years now. I read a post on an external site that mentioned some of the challenges that Apple might be facing to actually implement this. From a developer's perspective, I completely understand and surely shipping it without Apple ID login is better than no virtualization at all, but as a user, it's quite frustrating to get a new Apple silicon machine with the primary benefit of increased development speed and then run into this.

Since I'm just now getting up to speed on the new M1 chip, this feels like a brick wall in the street instead of a speed-bump. I have ALWAYS developed my mobile software in a VM and now I can't do that.

+1 for wanting an easy way to build an run inside a VM. This would dramatically speed up iteration when a bug is found in an old version of macOS and we're trying to fix it.

Ok, then, that was quite unexpected. My plan was to buy an Apple Silicon Mac and run MacOS in VMs to be able to test Intune MDM. But since Im not able to sign in with AppleId this won't work. I guess I scramble that idea, no Mac for me until this is solved. Sad story, wy make it so hard Apple?

So theres nothing apple want to change after an entire year? our use case is just real and reasonable, so plz just move fast in this damn limited

I just realized that. I've been virtualizing Linux on Mac for years, but now I have a use case for MacOS virtualized on an M1 Mac. It is absurd that Linux is fully functional when virtualized on an Apple Silicon Mac, but the virtualized MacOS is neutered, while virtualized Linux and even Windows are fully functional?

I use virtual machines for many different things. Isolated environments and alternate configurations are just two reasons which I can only assume that a very high percentage of people who use virtualization would also expect working virtualization to accomplish. For my purpose, if the App Store is broken, then essentially, the virtualization of Mac OS is broken.

Apple has had YEARS to resolve this issue. Apple has had VERSIONS of MacOS to resolve this issue. Apple has had GENERATIONS of Silicon to resolve this issue. I am led to believe Apple does not care or that Apple does not respect the needs of their users enough to provide effective resolution to this continuing disability. Yet we regularly get new emojis. WTF.

Let me step back from the WHY Apple does/does not do whatever it is that impairs the App Store on Virtualized Mac OS on Apple Silicon. And let me instead ask WHAT part of the virtualization and/or Apple Silicon breaks the App Store?

Can someone provide explanation as to what is happening that breaks the App Store?

Without capability to log into appleID environment the VM (I use UTM) is quite useless for my use case : sandbox administrator privileges, access to iCloud, testing on different app deployed from Appstore, etc into a corporate non privileged machine