I'm just getting started w/ container. I've been using lima. I thought that container should be investigated. I installed the .4.1 package, and started the tutorial. Imagine my surprise when the local dns entry could be created, but not set as a property. The command container system --help doesn't show property as a valid subcommand? OVERVIEW: Manage system components USAGE: container system <subcommand> OPTIONS: --version Show the version. -h, --help Show help information. SUBCOMMANDS: dns Manage local DNS domains logs Fetch system logs for `container` services start Start `container` services stop Stop all `container` services status Show the status of `container` services kernel Manage the default kernel configuration See 'container help system <subcommand>' for detailed help. > ~ container system property Error: Unexpected argument 'property' Usage: container system <subcommand> See 'container system --help' for more information. Some logs container system status apiserver is not running and not registered with launchd > ~ container system start Verifying apiserver is running... Installing base container filesystem... > ~ container system status Verifying apiserver is running... apiserver is running > ~ container system property Error: Unexpected argument 'property' Usage: container system <subcommand> See 'container system --help' for more information. I'm obviously missing something. Advice appreciated

Starting Xcode 14, iOS Simulator is able to communicate with APNs in order to register for notification in the sandbox environment. I created a sample test for this. A dumb iOS application that registers for notifications. It has UITests to automatize the tap on the consent popup (it is not possible to ask for the permission via CLI sadly). Once the application registers, the AppDelegate method didRegisterForRemoteNotificationsWithDeviceToken is called and the device token is sent to a local server application (node.js). The test itself creates an iOS 18.6 Simulator with xcrun simctl, builds such app and run the tests through through CLI with xcodebuild. Running this on my personal Macbook Pro M1 2021 goes well every time, so I wanted to bring it on Github Actions (arm64 macOS machines), in order to test the works on a open source library I'm building (hapns). Contacting Github support led me to test this on a macOS image running inside a VM inside a Veertu Anka container on my personal Macbook Pro, due to an VM architectural limit suspicion. The results were the same: iOS simulator isn't able to receive the device token. Not even didFailToRegisterForRemoteNotificationsWithError is called (tested through some network probes-requests that communicate to the server which checkpoints the process reached). So, as asked, I've setup a repro-case to be run in the VM and I've collected VM diagnostics ready to be tested and attached. Does anyone know if there is some unspecified (or specified but buried in the documentation) limit for this? Thanks. Github discussion link for further details, repro-case and so on: https://github.com/actions/runner-images/issues/12747

Hi everyone! I've considered this — what if Apple added a native system-wide feature in all of iOS, iPadOS, and macOS called “CrossRun” where you can natively execute non-App Store software like Windows or Linux apps natively on your device? But not in a sluggish emulator—this would use intelligent Apple-signed Just-In-Time (JIT) compilation inside the virtual containers, and the experience would actually perform fast and feel natural. This is my vision for CrossRun: Every developer, student, creative professional, and enterprise user who relies on specialized software—whether it’s legacy Windows tools, Linux-only applications, or vintage DOS and Classic Mac utilities—feels the pain of platform lock‑in. Artists can’t run niche Linux‑based graphics programs on their iPads. Engineers can’t test x64‑only binaries on Apple Silicon without juggling emulators. Retro‑gaming fans miss their favorite DOS titles. Even enterprises struggle to standardize on Apple hardware because critical Windows‑only applications won’t run seamlessly. If we don’t push for CrossRun now, the Apple ecosystem remains siloed: iPads and iPhones will continue limited to App Store apps, Macs will still need multiple third‑party VM tools, and countless workflows stay fragmented across devices. That means slower development cycles, extra licensing costs for virtualization software, and lost opportunities for education, creativity, and business efficiency. Without CrossRun’s universal runtime, we’ll still be rebooting into different environments or paying for separate virtualization apps—year after year. Apple already provides the building blocks: Rosetta 2, Virtualization.framework, Apple Silicon—and QEMU thrives as open‑source, battle‑tested code. With the next wave of Apple Silicon devices on the horizon, demand for cross‑architecture support, legacy‑app compatibility, and enterprise containerization is only growing. Delaying another year will cost developers, businesses, and users real time and money. Let’s show Apple that the community is ready for a truly universal, system‑integrated solution—right now. Key features we should demand in CrossRun: Built‑in Apple‑signed QEMU for all ISAs (x86, ARM, RISC‑V, PowerPC, 68k, MIPS, etc.) Rosetta 2 JIT for seamless macOS and Windows x64 support Metal‑backed 3D GPU passthrough and Vulkan→Metal / Direct3D→Metal translation Downloadable OS and app containers via the App Store or verified repositories (Ubuntu, Windows ARM/x64, Android, Haiku, ReactOS, FreeBSD, retro OSes) Predictive ML pre‑warm cache to speed cold starts Dynamic resource scaling (CPU, GPU, RAM) per container iCloud‑synced snapshots and shareable VM links for cross‑device continuity Customizable on‑screen controls (D‑pad, virtual buttons, trackpad, keyboard) on iPhone, iPad, and macOS Secure sandboxing via Virtualization.framework with VM disk encryption and MDM policy enforcement Virtual LAN and VPN passthrough for container networking Developer tooling (crossrunctl CLI, Xcode debugger integration, CI/CD support) Plugin ecosystem and container SDK for community‑published templates and translation layers Let Apple know it’s time to bake CrossRun into the system and unlock a universal runtime for every app, past and future, across iOS, iPadOS, and macOS.

After upgrading the virtual machines used for building and testing our macOS application, it seems that something new in Sequoia is preventing virtual machines from running anything signed with a Mac Development certificate. At first glance the issue seems very similar to this thread, but it could be unrelated. We are using the tart toolset to build and run our VMs. People seem to be having related issues there with Sequoia in particular. I have added the VM's hardware UUID to the Devices list of our account. I have included that device in the devices list of our Mac Development provisioning profile. I have re-downloaded the profile, ensured that it is properly getting built into the app, and ensured that the hardware UUID of the VM matches the embedded provisioning profile: Virtual-Machine App.app/Contents % system_profiler SPHardwareDataType | grep UUID Hardware UUID: 0CAE034E-C837-53E6-BA67-3B2CC7AD3719 Virtual-Machine App.app/Contents % grep 0CAE034E-C837-53E6-BA67-3B2CC7AD3719 ../../App.app/Contents/embedded.provisionprofile Binary file ../../App.app/Contents/embedded.provisionprofile matches However, when I try to run the application, it fails, and while I have searched the system logs to find a more informative error message, the only thing I can find is that the profile doesn't match the device somehow: Virtual-Machine App.app/Contents % open ../../App.app The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x6000039440f0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}} Virtual-Machine App.app/Contents % log show --info --debug --signpost --last 3m | grep -i embedded.provisionprofile 2025-01-21 16:33:32.369829+0000 0x65ba Error 0x0 2872 7 taskgated-helper: (ConfigurationProfiles) [com.apple.ManagedClient:ProvisioningProfiles] embedded provisioning profile not valid: file:///private/tmp/builds/app/.caches/Xcode/DerivedData/Build/Products/Debug/App.app/Contents/embedded.provisionprofile error: Error Domain=CPProfileManager Code=-212 "Provisioning profile does not allow this device." UserInfo={NSLocalizedDescription=Provisioning profile does not allow this device.} I don't understand why the provisioning profile wouldn't allow the device if the hardware UUID matches. I have also attempted to add the Provisioning UDID in the devices list instead, but the form rejects that value because it's a different format (the form specifically requests a hardware UUID for macOS development, and a provisioning UDID for everything else). If there is any debugging tool that lets me check a provisioning profile against the running hardware and print a more verbose reason for why it's not allowed on the device, please let me know. Otherwise I'd have to conclude that, since I haven't experienced this issue before on an earlier OS, it has something to do with virtual machines running macOS Sequoia. (The same Mac Development-signed application runs just fine on my MacBook Pro running 15.2, as well as the VM host, which is also running 15.2.) I have also tried resetting the VM's hardware UUID and adding that one to the devices list, to no effect. This is obviously seriously impacting our CI/CD pipelines to allow for proper UI testing of our application. If anyone is aware of any workarounds, I would love to hear them!

We have a Mac app that uses some restricted macOS entitlements, thus to test it we embed a development provisioning profile, that needs to contain the correct provisioning UDID. Typically, for test VMs, we extract the provisioning and UDID and add it to the developer portal and then re-generate the provisioning profiles. However when we try to do this in our newly created VM (Apple Silicon), our executable won't run, and macOS logs that the provisioning profile doesn't allow the device: 2025-06-12 12:37:52.168 E taskgated-helper[27489:e97da] [com.apple.ManagedClient:ProvisioningProfiles] embedded provisioning profile not valid: file:///Applications/foo.app/Contents/embedded.provisionprofile error: Error Domain=CPProfileManager Code=-212 "Provisioning profile does not allow this device." UserInfo={NSLocalizedDescription=Provisioning profile does not allow this device.} 2025-06-12 12:37:52.169 E taskgated-helper[27489:e97da] [com.apple.ManagedClient:ProvisioningProfiles] Disallowing com.company.foo because no eligible provisioning profiles found 2025-06-12 12:37:52.169 Df amfid[112:e99b0] [com.apple.xpc:connection] [0xb34c74a00] invalidated because the current process cancelled the connection by calling xpc_connection_cancel() 2025-06-12 12:37:52.169 Df taskgated-helper[27489:e97da] [com.apple.xpc:connection] [0x839144000] invalidated because the client process (pid 112) either cancelled the connection or exited 2025-06-12 12:37:52.169 E amfid[112:e91ac] [com.apple.MobileFileIntegrity.framework:default] Failure validating against provisioning profiles: &lt;private&gt; 2025-06-12 12:37:52.169 E amfid[112:e91ac] [com.apple.MobileFileIntegrity.framework:default] Restricted entitlements not validated, bailing out. Error: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=&lt;private&gt;, NSLocalizedDescription=No matching profile found} 2025-06-12 12:37:52.169 Df amfid[112:e91ac] /Applications/foo.app/Contents/MacOS/foo not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/foo.app/, NSLocalizedDescription=No matching profile found} The UDID for this VM does look weird, in System Profiler: But I can verify that this UDID string is present in the provisioning profile embedded in the app bundle: $ security cms -D -i /Applications/foo.app/Contents/embedded.provisionprofile | grep -i 7cd9234e9aa4fa8ba528ee417f857b2c993a20a3 &lt;string&gt;7CD9234E9AA4FA8BA528EE417F857B2C993A20A3&lt;/string&gt; I also tried deleting the manually added device from the Developer portal and installing Xcode on the VM and letting Xcode register the device, but I end up in the same situation there. Even after letting Xcode itself register the device, it says that "this device not registered to your account" and then when I click "Register device" it changes into " already exists". Has anyone else managed to get Mac development provisioning profiles to work in a VM?

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)

I installed the WWDC beta on UTM and I'm unable to find the option to disable the so-called "Natural Scrolling". Has this been removed and if so, can we get it put back? I use a mouse with scroll wheel and everything is going opposite the direction I expect in the macOS 26 VM.

We are using VZVirtualMachine instances in a Swift actor. It works fine but we hit a major problem when we decided that we want to attach it to a VZVirtualMachineView to show it / allow user interactions. VZVirtualMachineView and its virtualMachine property is isolated to @MainActor, so if we directly assign our vm instance to it, we receive a concurrency error: @MainActor public func createView() -> VZVirtualMachineView { let view = VZVirtualMachineView() view.virtualMachine = vm // x: Actor-isolated property 'vm' can not be referenced from the main actor return view } Is there any way we can make this work?

Can the Xcode 26 code assist feature be used in a macOS 26 virtual machine? I am not seeing a way to enable it... Also asking on https://github.com/insidegui/VirtualBuddy/discussions/524

I’m encountering an issue when trying to start a macOS VM using Apple’s Virtualization framework in a sandboxed environment. When I create a standalone Xcode project, the VM launches successfully. However, when I integrate the same code into my existing project—where the VM is launched by a service started via launchd and running in a sandbox—it fails with the following error: Internal Virtualization Error: Failed to issue USB HCI sandbox extension To resolve this, I tried adding the com.apple.security.device.usb entitlement. But after doing that, the app started crashing with the following trace : Application Specific Signatures: SYSCALL_SET_USERLAND_PROFILE Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_secinit.dylib 0x19a7141bc _libsecinit_appsandbox.cold.9 + 84 1 libsystem_secinit.dylib 0x19a713324 _libsecinit_appsandbox + 2080 2 libsystem_trace.dylib 0x18c2326cc _os_activity_initiate_impl + 64 3 libsystem_secinit.dylib 0x19a712ab0 _libsecinit_initializer + 80 4 libSystem.B.dylib 0x19a72a32c libSystem_initializer + 280 5 dyld 0x18c162efc invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 444 6 dyld 0x18c19f864 invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 324 7 dyld 0x18c1bf58c invocation function for block in mach_o::Header::forEachSection(void (mach_o::Header::SectionInfo const&, bool&) block_pointer) const + 240 8 dyld 0x18c1bc318 mach_o::Header::forEachLoadCommand(void (load_command const*, bool&) block_pointer) const + 208 9 dyld 0x18c1bda58 mach_o::Header::forEachSection(void (mach_o::Header::SectionInfo const&, bool&) block_pointer) const + 124 10 dyld 0x18c19f334 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 516 11 dyld 0x18c162cb4 dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 176 12 dyld 0x18c16e530 dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const + 44 13 dyld 0x18c1848b0 dyld4::APIs::runAllInitializersForMain() + 88 14 dyld 0x18c147e00 dyld4::prepare(dyld4::APIs&, mach_o::Header const*) + 3092 15 dyld 0x18c1471d8 dyld4::start(dyld4::KernelArgs*, void*, void*)::$_0::operator()() const + 236 16 dyld 0x18c146b4c start + 6000 I suspect this might be due to the provisioning profile, which doesn’t seem to include the required entitlement. However, I haven’t found a way to explicitly add this entitlement to the provisioning profile. My questions are: How can I add com.apple.security.device.usb to the provisioning profile? Is there a way to confirm that adding this entitlement would resolve the issue? Are there recommended steps to debug and test Virtualization framework usage in a sandboxed environment (especially when launched as a service)? I also tried disabling SIP and AMFI, but the crash still occurs. Is there a better way to work around or test this in development? Any insights or suggestions would be greatly appreciated!

Hello, According to the official documentation, the macOS Virtualization Framework currently supports only macOS and Linux guest operating systems. I would like to know if there is any way—officially or through a supported workaround—to run Windows 11 as a guest using this framework. Additionally, is there any indication or roadmap suggesting that support for Windows guests might be introduced in a future release, such as in macOS 16? Any insights or official clarification would be greatly appreciated. Thank you.

Hello, I'm developing a macOS application that uses the Virtualization framework to run Linux virtual machines (specifically Ubuntu and Fedora) on Apple Silicon Macs. I've noticed that while the macOS host properly supports all trackpad gestures, the two-finger tap gesture for right-click does not work within the Linux guest. Only the primary click is recognized. This behavior is consistent across different Linux distributions and desktop environments (GNOME, KDE, etc.). I would like to confirm: Is the macOS Virtualization framework expected to support trackpad gestures such as two-finger tap for right-click within Linux guest VMs? If not currently supported, is there a known workaround to enable right-click functionality for the trackpad in Linux guests? (e.g., configuration changes in the VM, Linux kernel input modules, or framework-level adjustments.) Any insights or suggestions would be greatly appreciated. Thank you!

I’ve developed a virtual machine manager application using the macOS Virtualization framework. The application currently supports both NAT and bridged networking configurations. I’m now looking to implement host-only networking, where the guest VM can communicate with the host but not with external networks. Is this networking mode supported by the Virtualization framework, and if so, what is the recommended approach to set it up? Additionally, I would like to implement port forwarding from the host to the guest (e.g., redirecting traffic from a specific port on the host to a port on the guest). Is there a way to configure port forwarding using the built-in APIs of the Virtualization framework, or would this require a custom networking solution? Any guidance or best practices for implementing these features within the constraints of the framework would be greatly appreciated.

Hi, been exploring macOS VM on both Parallels and UTM and they lack some "GPU/graphics" things vs native MacOS which could be useful on some situations (testing some non trusted graphics apps on a Mac VM) so providing similar usefulness as Windows Sandbox.. Current limitations: 1)In MacOS VM night mode doesn't work.. 2)HDR support isn't exposed even when enabling HDR on host 3)missing GPTK support for the Paravirtual GPU (Paravitual GPU supports Metal but isn't enough for GPTK to work which complains about unsupported GPU).. 4)OpenCL is supported but only the CPU device.. so expose GPU device in addition to current CPU only device.. 5)OpenGL only supports the software renderer.. I assume OpenGL driver on Apple M1-4 GPUs being Metal based, and being Metal supported no reason for software renderer only thanks..

Hi, REQUEST 1: seems Microsoft is ahead of Apple in X86 ARM emulation support at least in features supported.. see: https://blogs.windows.com/windows-insider/2024/11/06/announcing-windows-11-insider-preview-build-27744-canary-channel/ x64 emulated applications through Prism will now have support for additional extensions to the x86 instruction set architecture. These extensions include AVX and AVX2, as well as BMI, FMA, F16C BMI1/2 and F16C aren't yet supported by Rosetta.. would be useful for games like Alan Wake 2.. so asking for Rosetta equaling features to Prism emulator.. REQUEST 2: there is no way to currently enable AVX1/2 on Rosetta Linux.. on macOS using export ROSETTA_ADVERTISE_AVX=1 does the trick.. but not on Linux VM's.. tested setting this via: /bin/launchctl setenv ROSETTA_ADVERTISE_AVX 1 on Mac before VM launch and inside Linux VM but AVX2 isn't exposed..

Hi, Since recently there is interest in having faster x87 translation speeds than Rosetta offers.. mainly some old PC games getting stuck at less than 5fps using Wine that uses Rosetta..( some world of warcraft game for ex.).. so main case right now, is games using old fmodex library versions (dll or statically)that uses heavy x87 instructions for audio processing , and such games not being threaded ,stalls the render threead, which is the same thread.. Luckily there is a hack, see: https://github.com/Lifeisawful/rosettax87 ”This is an experimental project that modifies Apple's Rosetta technology to use less precise but significantly faster x87 instruction handlers. The benchmarks show approximately 4-5x performance improvement for x87 floating-point operations.” but limitations are: 1)it runs only on specific Mac version (15.4.1) due to searching some fixed offsets in current rosetta library that may change with mac updates.. 2)requires to run two binaries (a server and the launcher program).. 3)currently doesn’t seem to accelerating x87 instruction on Linux programs/binaries i.e. lacking support for Rosetta on Linux if Apple supports similar technology, it could providing some enviroment variable like ROSETTA_FAST_X87 for enabling/disabling this fast emulation similar to how Rosetta AVX support not enabled by default.. thanks..