Tart: VMs on macOS using Apple's native Virtualization.Framework

Original Article ↗ Hacker News Discussion ↗

Developers are examining Tart, a macOS tool that wraps Apple’s Virtualization.framework to run macOS and Linux VMs and distribute images via container registries, as a streamlined way to automate CI and dev environments on Apple Silicon. Much of the debate centers on performance and architecture trade‑offs—virtualization vs full emulation for x86 on ARM, Rosetta 2’s role for running Intel binaries inside Linux VMs, filesystem and Docker performance on macOS, and how far 8GB machines can realistically be pushed. Licensing is another flashpoint, with Tart’s non‑OSS, core‑based “Fair Source” model prompting some to prefer open alternatives like UTM, Lima/Colima, VirtualBuddy, or custom QEMU setups.

Overview of Tart and Its Pitch

  • CLI tool wrapping Apple’s Virtualization.framework to run macOS and Linux VMs on Apple Silicon.
  • Key differentiator: uses OCI/container registries for VM images, enabling workflows similar to container images (build, push, pull, reuse).
  • Users praise the clean CLI, easy scripting, and integrations (Packer plugin, GitLab/Buildkite, CI).
  • Especially valued for reproducible macOS test environments and quick setup from IPSW to VM.

Licensing and Business Model

  • Uses a Fair Source–style license with per-core “seats” for organizations; personal use and small server installs are free up to a core limit.
  • Some see the license as restrictive/confusing, worry about organizational compliance, and dislike “BSL-esque” non‑OSI terms.
  • Others note that the LICENSE and website are explicit, and that commercial users should always check terms.
  • Earlier versions were AGPLv3; those commits remain in the repo and can be reused or forked.

Virtualization vs. Emulation vs. Containers

  • Long subthread debating terminology:
    • One side: in current industry usage, “virtualization” implies running guest code directly on the host CPU (same ISA), distinct from emulation.
    • Other side: historically, emulation is a technique within virtualization; categories overlap and marketing has distorted terms.
    • General agreement that containers are distinct (OS-level isolation, shared kernel), though some note modern container stacks use virtualization underneath.

x86_64 on Apple Silicon and Rosetta

  • Multiple explanations that full x86 OS guests require emulation; Rosetta-style binary translation is suitable only for userspace, not kernels.
  • Recommended approach: run an aarch64 Linux VM and use Rosetta 2 inside the VM (via Apple’s documented support) or similar mechanisms to run x86_64 binaries; much faster than full-system QEMU emulation.
  • Users report UTM’s x86_64 emulation as “practically unusable” for heavier workloads; native ARM VMs are fine.

Ecosystem Comparisons and Alternatives

  • Alternatives mentioned: Apple’s own Virtualization/Hypervisor frameworks (DIY), virt, Lima/Colima (Linux-focused), UTM, VirtualBuddy, Viable, VMTek, OrbStack, Multipass.
  • Tart is seen as distinctive mainly for macOS guest support plus image-registry workflows and CI tooling.
  • Some argue you can get most functionality with QEMU/Hypervisor.framework if you invest the time; others value Tart’s polished UX.

Performance, Hardware, and Dev Experience

  • Concerns about filesystem performance in macOS VMs and Docker; VirtioFS has improved things but still lags native Linux.
  • Suggestions: use sync tools like Mutagen; or run Docker entirely inside a Linux VM.
  • Debate over adequacy of 8GB RAM: some report smooth workloads (even video editing), others find modern IDEs and larger projects unusable and recommend 16GB+ for VM-heavy/dev use.

Use Cases and Legal Notes

  • Used heavily for Mac CI, testing management/workflows, macOS DEP-like enrollment scenarios, and quickly booting into Recovery to tweak security settings.
  • macOS images on GHCR raise questions; one comment cites macOS EULA carve-outs for “Permitted Developer Services” like CI, though layering support in Tart is currently absent.
  • GPU passthrough for macOS guests is limited to a paravirtual GPU; suitability for LLM workloads is unclear.