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"

/me tosses VM in trash

I wish I'd known this before setting up the VM. Sonoma isn't like previous OSes; I can't sacrifice an old machine to it. This means I won't be testing for several months.

I'm okay with that, but it's nice to contribute. 😀

Why bother listing reasons why Apple ID should work in VMs? It is never going to work and Apple has no intention to make it work. It's been broken for years.

@eskimo Hi! Thanks so much. What is this new download? Is it related to this problem? Do we install it on the VM or in the host? https://developer.apple.com/download/ Regardless, I tried on the host and the VM w/o success.

How do we update our VM running macOS 14 beta 1 to beta 2? Thanks!


Device Support for macOS 14 beta 2
Install Device Support for macOS 14 beta 2 if installing the macOS Seed in a virtual Machine fails on a host Mac.
Released
June 21, 2023 
Build
1700B21
Download Device Support Image

Device Support for macOS 14 beta 2
1700B21

chrisalbertson wrote:

It is never going to work and Apple has no intention to make it work.

I’d appreciate you not posting extraordinary claims without solid evidence to back them up.


Bolsinga wrote:

What is this new download?

Please start a new thread for this. This thread is already long enough )-:

Share and Enjoy

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

@eskimo Thanks for the information regarding this. I appreciate the efforts you and your team have been putting into this per your post of a couple weeks ago. That said, I'd like to offer my .02:

I've noticed that the macOS 14 beta system seems to be tied to an Apple ID; I was running Sonoma beta 1 in a VM and wasn't able to upgrade it to beta 2 without manually downloading the IPSW and re-building the VM. I do get the requests for updated betas on my host Mac (13 inch M1 MBP), but I'm a bit hesitant to actually run the beta on the host -- namely because I've got a thesis going, and would understandably like to wait until it's over before I go updating.

It is also notable because I wasn't able to use a Mac VM as part of my thesis research and instead moved a fair amount to Windows and Linux VMs that don't have issues with accessing functionality. For example, it would have been nice to see how HomeKit in Ventura and Sonoma played with the lab network, but I was fundamentally unable to do this with a VM.

This has been frustrating me since the day I got my Apple Silicon Mac. I need virtual environments to build and debug my application under new OSes. I vastly prefer doing that under a VM rather than having to boot from a partition or use a dedicated machine.

Help us, Apple; you're our only hope.

I've just encountered this limitation after downloading macOS Sonoma 14 Beta 5 and spending some time debugging it. We basically need to test under Sonoma and having no possibility of using AppleIds is quite limiting...then I wonder, why to allow to use VMs for it? what's the purpose of having it?

I hope Apple takes this into consideration. We really need this.

Sam.

+1 for this feature. I use VMs to test different developer technologies for which Store sign-in is required.

I have a particular use case which falls outside of development, specifically: I have a client who wants to use multiple iPhones to do multi-camera recording and monitor the video from ALL of the cameras in real-time. It's easy to use screen mirroring to mirror one phone to their laptop, but it's not possible to mirror multiple screens onto the same machine (obviously). Running multiple VMs to act as AirPlay receivers would work perfectly for this -- except that the VMs would have to be signed in to the same Apple ID to be able to mirror the display, and I can't sign in to any Apple ID at all.

If there is some other workaround, I'd be pleased to hear it.

I don’t know how to upvote as I tried and doesn’t seem to work but can we fix this and nested virtualization for the love of all that is worthwhile In this world?

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

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

AppleID Login failing in virtualized OS
 
 
Q