Running built macOS app in 13.3 beta VM on M1?

I managed to get a macOS 13.3 beta install running in Parallels on my M1 VM, but it was really hard to get my app (built on my 13.2.1 M1 native macOS) installed on it, because so many features are unsupported in the VM (e.g. I can't drop files onto it like I can with other OSes, or on Intel; I can't log in with my Apple ID because Apple doesn't allow that, etc.).

I finally copied it over using File Sharing from the VM, but the virtual OS won't launch it. It throws up a vague alert saying "The application can’t be opened." If I try to launch it from the command line, I get

The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600000f2da10 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

I assume it's some kind of code signing/gatekeeper issue, but I don't really know.

I also tried this using the Apple virtualization framework and sample virtual machine tools (neat that those exist). I'm pretty sure this is exactly what Parallels is using internally, btw. It lacks a LOT.

Is there any way to make running macOS betas in a VM a viable way of testing?

About the additional features you'd like from the virtual machines, I recommend filing feature requests with the Feedback Assistant. This is how the requests are tracked to influence the products.

The code sample is intended to teach how to use the API rather than being a real application. I would recommend using one of the real application built on top of Virtualization for serious wok like you are trying to do.

Regarding the failure to launch, it's hard to tell from the error message alone but my first guess is the signature of the app. If the app was built with self-signing for the local macOS, the signature wouldn't match in the VM.

One way to gather more information about the problem might be to look at the system logs. This can be done in the "Console" app or with the log command on the command line (e.g. log stream). If that's the issue, you'd just need to sign the app as if you were deploying to physical hardware before running it in the VM.

I hope this helps.

Oh I'm quite aware that the sample code isn't intended to be a "real" application; I only used it to test the approach, and to see if it was any better than Parallels at the same task (it is, because I was able to directly create the VM from the the beta image). In fact, it was very exciting to have so much functionality in sample code. What's lacking is Parallels' VM. It doesn't share the clipboard, and doesn't allow dragging and dropping of files between the host and guest Finders, something that does work for the other guest OSes like Windows.

What is lacking in the macOS virtualization framework is documentation. It's not clear, for example, how one would change the display configuration of a running VM (e.g. in response to a VM window size change), or how to set up the shared clipboard, or what a "memory balloon" device is.

I've already filed a bug about not being able to log into iCloud, which has also been reported on this forum by many others. FB12006346

Looking at the Console, it definitely seems to be a self-signing issue.

So I go to sign my app, but I can't. I don't know why, but I get errors saying it couldn't communicate with Apple, which seems unlikely, and that no provisioning profile for my app was found. But it's supposed to be managing that automatically.

THIS IS TOO HARD.

Copying a app you’re building to a VM is like copying the same app to any other Mac:

  • Build the app universal, or for the architecture of the destination Mac.

  • Make sure any Apple silicon code is signed.

    • You can use an ad hoc signature (Sign to Run Locally in Xcode parlance).

    • Better yet, sign it with Apple Development.

  • If the app uses a provisioning profile, make sure that the Mac is listed in that profile.

  • Avoid Gatekeeper entanglements by either copying the app using a tool that doesn’t apply quarantine or by manually removing the quarantine on the destination. I typically do the former, copying with scp.

This can be a pain but its no more of a pain in a VM than it is on real hardware.

Xcode should make this easier. After all, it could reuse all the infrastructure set up that it already has for iOS and its descendents. I know we have bugs on file requesting that but I’ve no info to share as to if or when it’ll happen.

Share and Enjoy

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

To answer some of the questions:

It's not clear, for example, how one would change the display configuration of a running VM (e.g. in response to a VM window size change) or how to set up the shared clipboard

This isn't supported in macOS Ventura. I would recommend filing feature requests :)

You can also file bug reports in the Feedback Assistant when something isn't clear enough in the documentation. This is very valuable feedback as it's not always obvious where the documentation is too wordy, and when it's lacking content.

or what a "memory balloon" device is.

A "memory balloon" is a concept that is exclusive to virtual machines. There is some documentation on https://developer.apple.com/documentation/virtualization/vzvirtiotraditionalmemoryballoondevice?language=objc

The general idea is to be able to reclaim some memory that the guest operating system is using. With Virtualization Framework, memory is allocated on demand such that a guest OS only uses as much as it used up to the maximum size configured.

The challenge is the host macOS has no visibility into the guest OS's page table. As a result, the host doesn't know which memory pages are in used and which ones are caches or unused data.

The "memory balloon" is a solution to coordinates the guest and host page table to reclaim memory. The balloon can "grow" in the guest memory, which tells the drivers to return unused pages to the host macOS.

In the virtual machine literature, this technique is known as memory ballooning.

Running built macOS app in 13.3 beta VM on M1?
 
 
Q