AppleID Login failing in virtualized OS

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

  • This is essential.

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

Apple Recommended

  • This is a frustrating, unnecessary limitation. My use case is to isolate development environments, and I was able to do this with macOS before.

  • Thank you for clarifying this. At least I now know I wasn't screwing up in my UTM VMs. I will file a feature request; I'd like to be able to use VMs for additional TestFlight testing for apps with System Extensions.

Add a Comment

Replies

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?

  • The ease of creating and using virtual machines could be a use benefit for developers, but not being able to log in with your Apple ID is limiting our use:

    • Download Apps from the App Store • Using Xcode to build and debug apps • Using iCloud in apps

  • I'd like to be able to run Mail.app to access my personal iCloud email on a company Mac, use my iCloud Keychain sync'ing, be able to stage clean environments to prototype mac-related ci code (code signing and notarization must work). The iCloud/appleid/dev account might be the same as the one on the host Mac or a different one.

  • Project work for me requires isolated environments, clients require diff desktop profiles. Anti-virus is different each time, VPN is different and doesn't work with other VPNs.My use case is that when I work on multiple projects, I build out a VM to their enterprise standards and work with the software that the company uses. Not for performance but to limit the number of laptops I have to carry. :-) I also leverage software from my base image to do my creative work and share the assets between.

@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

  • +1 for this

  • +100 for this

  • +1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 for this

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

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.

  • I'd like to be able to run Mail.app to access my personal iCloud email on a company Mac, use my iCloud Keychain sync'ing, be able to stage clean environments to prototype mac-related ci code (code signing and notarization must work). The iCloud/appleid/dev account might be the same as the one on the host Mac or a different one.

Add a Comment

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.

Add a Comment

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

I learned about virtualisation possibilities with macOS and Apple Silicon in videos from WWDC 2022. I bought a MacBook Pro M1 with 64GB RAM and 2TB disk storage so I can run several VMs for my use cases.

Beside some use cases described above I want to mention the usage of Homebrew and MacPorts. With VMs it is possible to use both.

I created a VM for testing how to compile Joplin for Apple Silicon. A VM allowed me to use HomeBrew while I have MacPorts installed on my physical system. The usage of an Apple ID in a VM is essential to have the same workflow as in a physical system (Xcode, notarise, etc... ).

  • I was really excited to get a Mac M! and even maxed it out in all aspects for the sole purpose of testing and developing with virtual machines. Had I known this would be an issue, I would have NEVER bought an Apple Silicon machine and would've slowly veered away from the Apple ecosystem. Looks like my path is now from Apple hater to Apple lover and now back to Apple hater! Why would you put out powerful machines just to limit their use? I was also dumb enough to get a maxed-out iPad Pro too.

Add a Comment