# UTM: why iOS gets UTM SE while macOS gets Hypervisor

> UTM is a QEMU based system emulator that ships as two very different products: on iOS, dynamic code generation is unavailable without a jailbreak, so UTM SE swaps JIT for a threaded interpreter and gives up speed. On macOS the same codebase can use Hypervisor.framework and can boot macOS guests outright.

**utmapp/UTM** — Virtual machines for iOS and macOS

- Repository: https://github.com/utmapp/UTM
- Website: https://getutm.app
- Stars: 35,714 · Forks: 1,840
- Language: Swift
- License: Apache-2.0
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/utmapp-utm

## QEMU does the emulation and a Swift frontend does the rest

The project's own summary is that UTM is a full featured system emulator and virtual machine host for iOS and macOS, based off of QEMU, so you can run Windows, Linux and more on a Mac, an iPhone or an iPad. What the repository root shows is how much sits around that core. There is a QEMUHelper, a QEMULauncher, a QEMURenderServer and an iOSHelper directory, which points to a multi-process design rather than one binary, plus Renderer, Remote, Services, Intents and Scripting directories and a UTM.xcodeproj. The README states the frontend was designed from scratch for macOS 11 and iOS 11 and later, which sets a floor for both platforms. Graphics arrive in two forms, VGA mode through SPICE and QXL, and a text terminal mode, and USB devices are supported. The practical consequence for anyone evaluating it: this is an app with guest operating systems inside it, so the storage and memory you give the guest come off the same machine that runs the emulator.

For anyone planning to build the thing, the root also shows the paperwork. Fifteen translated READMEs sit next to README.md, covering German, Japanese, Russian, French, Spanish, Czech, Bengali, Korean, Ukrainian, Polish and three Chinese variants, while the application itself ships only zh-HK.lproj, zh-Hans.lproj and zh-Hant.lproj. The documentation has been carried much further than the interface. CodeSigning.xcconfig.sample means a fork supplies its own signing configuration before anything will build, and the two developer guides are in the tree as Documentation/MacDevelopment.md and Documentation/iOSDevelopment.md, with the README summing up neither.

## Dynamic code generation is what UTM SE gives up

QEMU accelerates with TCG, and TCG needs dynamic code generation. On iOS, dynamic code generation requires either a jailbroken device or one of the workarounds that exist for specific iOS versions, so the fast path is largely closed off. UTM SE, the slow edition, replaces the JIT with a threaded interpreter that performs better than a traditional interpreter but slower than JIT, and the README says the technique is similar to what iSH does for dynamic execution. The payoff is that UTM SE needs no jailbreaking and no JIT workaround, so it can be sideloaded as a regular app. The cost lands on every instruction the guest executes. That trade is invisible in a feature list and dominates in practice: a guest built for the same architecture runs at a fraction of the speed under the interpreter, and the full UTM and UTM SE builds are not interchangeable for anything timing sensitive. Choose SE when the guest is a terminal or a lightweight Linux and speed does not matter. Choose the JIT build only where JIT is actually reachable.

## Thirty plus processors on the Mac, four architectures on iOS

Processor coverage differs sharply between the two editions, and the README gives the numbers. The full build claims 30+ processors including x86_64, ARM64 and RISC-V. UTM SE, in order to optimise for size and build times, includes only ARM, PPC, RISC-V and x86, each in both 32-bit and 64-bit variants. So an iOS user is not choosing a slower path through the same product, they are choosing a smaller catalog. A guest that needs a processor outside that list cannot be built on the SE path at all, and ARM64 in particular is named among the full build's highlights while the SE list is written as ARM and x86 with 32 and 64-bit variants, so check the exact variant your guest needs before committing. Two more lines from the README matter for the same decision: the emulator claims VGA graphics through SPICE and QXL, and a text terminal mode is available as well. A text session avoids the graphics path entirely, which is where an interpreter based backend costs the most.

## Hardware acceleration and macOS guests are macOS only

The Mac build gets two capabilities the iOS build cannot have, and they are listed separately in the README under additional macOS features. The first is hardware accelerated virtualization using Hypervisor.framework together with QEMU, which is the path that turns a Mac into a fast host. The second is booting macOS guests with Virtualization.framework on macOS 12 or later, so a Mac can run macOS inside macOS. Both of these are Apple platform facilities that iOS does not expose, and the README does not offer a substitute for either on iPhone or iPad. That is the single most useful thing to know before choosing a device: on a Mac you are running an accelerated hypervisor, and on an iPad you are running the interpreter from UTM SE, because the JailbreakInterposer directory at the repository root is the only sign of the jailbroken route and it is a code path, not a feature you get by installing the app. The practical test is the guest, not the host: anything that depends on a full graphics stack or on real CPU speed belongs on the Mac.

## Two download pages, and no install command anywhere

The Install section of the README is four lines long and contains no commands at all. For iOS it names one address, https://getutm.app/install/, and labels it UTM (SE) for iOS, which tells you the SE build is the one the project points iPhone and iPad owners at. For the Mac it names a second address, https://mac.getutm.app/, and the same section states that UTM is also available for macOS. So there is no command to copy and no package manager entry to add: distribution happens through those two sites, and sideloading is the documented route for the SE build on iOS. The README does not say where the non SE iOS build is distributed from beyond that install page, and it does not describe disk image formats, disk creation, or how a downloaded image gets attached to a guest. Getting a bootable image into a guest is left entirely to the linked sites. The project does state that VMs can be created, managed and run directly from the device, so the application itself is meant to handle that, but the mechanics live on those pages rather than in the repository.

## Apache 2.0 over (L)GPL pieces and statically linked gstreamer

The licence story has a second layer, and the README is direct about it. UTM itself is distributed under the permissive Apache 2.0 licence. It also uses several (L)GPL components, most of which are dynamically linked, but the gstreamer plugins are statically linked and parts of the code are taken from qemu. The project asks redistributors to be aware of that, and that request is the whole message. If you only run the app, the mix does not affect you. If you intend to redistribute it, whether as a fork, a bundled image, or a build inside another product, then the copyleft terms of the linked and statically linked components come with it, and the README does not enumerate which components fall in which category, so you would have to work that out from the build itself. The frontend pulls in four MIT or BSD licensed libraries, IQKeyboardManager, SwiftTerm, ZIP Foundation and InAppSettingsKit, and those are the permissive part of the tree. This is not legal advice, just the boundary the project draws for itself.

## Three releases in a row tagged Beta

The version history is the thing to read before deploying anything. The three most recent releases are v5.0.4 on 2026-08-01, v5.0.5 on 2026-09-02 and v5.0.6 on 2026-09-24, and every one of them carries the Beta tag in its name. The last push to the repository was on 2026-09-25, the day after v5.0.6 was cut, so the tree is being worked on rather than parked. What the sequence does not give you is a non Beta 5.x release to point at in a script or a managed device list, so whether a build counts as stable is a decision you have to make from the release notes and the linked CI workflow rather than from the tag string. Patch level fixes are arriving as betas too, which means bug fixes and format change arrive together. Pin an exact version and read the diff between the two you currently run and the one you want, especially if you keep disk images, since image compatibility across a major bump is not something the repository states anywhere.

## iSH and a-shell are named next to it, and they solve smaller problems

The README names two related projects, and the difference in approach is worth being precise about. iSH emulates a usermode Linux terminal interface for running x86 Linux applications on iOS, which means it interprets user space code rather than booting a guest operating system with its own kernel, MMU and devices. a-shell goes further in the other direction: it packages common Unix commands and utilities built natively for iOS and reachable through a terminal interface, so there is no emulation layer at all. UTM sits above both of them, and it is also where the interpreter technique comes from, since UTM SE credits the same general approach iSH uses for dynamic execution. The consequence for choosing a tool is a size and scope question rather than a quality one. If what you need on an iPhone is a shell and a handful of Unix commands, either of those is a far smaller download than a virtual machine host. If you need an actual guest system with its own kernel, UTM is what runs it, and on iOS you accept the interpreter to get it.

## Conclusion

UTM fits an Apple device that genuinely needs a guest: a Mac or an iPad with disk space and patience for emulation, or an iPhone that mostly needs a terminal, where UTM SE sideloads as a regular app. Skip it if the guest must run fast on iOS, because the Hypervisor.framework acceleration path and the Virtualization.framework path for booting macOS guests are both macOS only. If you plan to deploy the 5.0 line, check whether a release without the Beta tag exists for your needs, since the last three releases all carry one. First, confirm the guest you have in mind needs an architecture inside the ARM, PPC, RISC-V and x86 list that UTM SE builds, because a full UTM install supporting 30+ processors is a different download from what an iPhone can install.

## FAQ

### Is UTM or VMware better?

The README does not compare UTM to VMware. It states UTM's own scope: full system emulation through QEMU for iOS and macOS, with hardware accelerated virtualization using Hypervisor.framework on macOS and macOS guests bootable through Virtualization.framework on macOS 12 or later.

### What is the UTM app?

A full featured system emulator and virtual machine host for iOS and macOS, based off of QEMU. It lets you run Windows, Linux and more on a Mac, an iPhone or an iPad, with VGA graphics through SPICE and QXL or a text terminal mode.

### What is a boot iso image in UTM?

The README does not describe boot images or disk formats, so it gives no answer to that. It does say VMs can be created, managed and run directly from the device, and it points to https://getutm.app/install/ for iOS and https://mac.getutm.app/ for macOS for the details it leaves out.

### Does UTM require a jailbreak?

Not for UTM SE. It uses a threaded interpreter instead of QEMU's JIT, so it needs no jailbreaking and no JIT workaround and can be sideloaded as a regular app, at the cost of running slower than JIT. The full UTM and QEMU build wants dynamic code generation for maximum performance, which on iOS requires a jailbroken device or a workaround for specific iOS versions.

### What is the com.utmapp.utm app?

The README does not state the bundle identifier. It describes UTM as a QEMU based system emulator and virtual machine host for iOS and macOS, gives https://getutm.app/install/ as the iOS route and https://mac.getutm.app/ as the macOS one, and notes that continuous integration hosting is provided by MacStadium.

## Sources

- [Official documentation](https://getutm.app)
- [Official README](https://github.com/utmapp/UTM#readme)
- [Project repository](https://github.com/utmapp/UTM)
- [Release notes](https://github.com/utmapp/UTM/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/utmapp-utm