AppleID Login failing in virtualized OS

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

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