touchHLE: most apps do not run, the project says so, and 64-bit iOS is never on the list

The emulated CPU only runs the app binary and a handful of libraries

The architectural claim is in the second paragraph and everything else follows from it. touchHLE performs high-level emulation rather than low-level, so it does not simulate the touch hardware. Instead of running iOS inside the emulator, touchHLE takes the place of iOS and supplies its own implementations of the system frameworks, naming Foundation, UIKit, OpenGL ES and OpenAL among them. What the emulated CPU actually executes, which is a third-party instruction-set emulator rather than something written here, is therefore just two things: the application binary you supply, and a handful of libraries that are committed to the repository in a directory named for that purpose. Everything the app calls outside its own code is handled by reimplementation. That is why the project can be written in Rust and shipped as a single desktop binary, and it is also why a large amount of behaviour depends on how faithfully a framework has been rebuilt rather than on any translation layer.

The majority of apps do not work and the project says so

The README states the compatibility position in bold and without softening it: this does not mean that all apps for these OS versions work. The vast majority of iOS 2.x, 3.x and 4.x apps do not currently run, and the ones that do are generally games, with the reason given plainly, that support for other apps is not prioritised because it is more complex and less fun. Compatibility will improve gradually with contributions, and a crowdsourced database at a separate site tracks which apps work. Then comes the line that sets expectations harder than any of the above: the project does not take requests, so please do not ask it to support your favourite game. Read together, the three statements describe a scope that is deliberately narrow. Current targets are iPhone, iPod touch and iPad apps for iPhone OS 2.x, 3.x and iOS 4.0.x, with high-DPI support, later 4.x releases and iOS 5 and 6 named as longer-term work, and 64-bit iOS described as never.

Only a binary you already hold legally, and already decrypted, is usable

The disclaimer section is short and it is the part to read before anything else. The project states it is not affiliated with or endorsed by Apple, and that iPhone, iOS, iPod, iPod touch and iPad are trademarks of Apple. Then one sentence carries the condition of use: only use touchHLE to emulate software you have obtained legally. The usage section adds the practical half of that: the app binary must be decrypted to be usable. So the tool does not take an encrypted store bundle off a device or ship anything, and the decryption step is on the user, which means the legality question turns entirely on where the binary came from. The README also flags that the compatibility database may contain outdated or inaccurate information, so it is a starting point rather than an index you can rely on. Nothing in the repository bundles, links to or recommends a source of applications.

Completeness is set by whichever game a contributor wanted

The development status section explains why the framework coverage is uneven, and the explanation is honest rather than apologetic. Most contributors are interested in getting one particular game working, and contribute the features that game happens to need. So completeness varies a lot between APIs. UIKit is described as easily the most hacky and incomplete of the large frameworks that have been implemented, because most games do not use much of its functionality, while the OpenGL ES and OpenAL implementations are probably complete enough to cover a large number of early apps, because games lean on them heavily. Read as an engineering document, that is a rational allocation of effort with a predictable shape: whichever framework nobody needed is the one you will hit. The section also records the project's history, in development since December 2022, originally one person's full-time passion project, with volunteers contributing in their free time since the February 2023 release, and says plainly that there have been only a handful of releases and no promises can be made about the future.

The default feature statically bundles the windowing and audio libraries

The manifest is set up so one binary ships without system packages. The default feature list is a single entry, `static`, which enables `sdl2/bundled`, `sdl2/static-link` and a static build of the OpenAL Soft wrapper. So by default the emulator links its windowing and audio libraries in rather than expecting them installed, which is what makes a single downloaded file work on a clean machine. The crate is built as both a library and a binary, with `crate-type` listing `cdylib` and `rlib` and a separate binary target, and there is a link in a comment to a discussion about producing both from one package. Two dependency notes are worth reading. One font-related library is pinned with a comment saying the version exists so an underlying type can be reached and must be bumped if the other one updates. And the audio codec library carries a long note that most of its codecs are thought to be unpatented or freely licensable as of 2024, that all AAC profiles except the simplest one have active patent claims, that the feature therefore enables only that one profile, and that none of it should be understood as legal advice.

Patches are reviewed on Gerrit and the apps directory is committed

Two repository details affect anyone contributing or cloning. First, the repository description says plainly that it is used for issues, releases and continuous integration, and that patches are submitted on a Gerrit instance at a different domain, so the review workflow is not GitHub pull requests and a patch sent to GitHub will not be picked up. Second, the tree contains a committed `touchHLE_apps` directory, which is the same directory the Android instructions tell users to drop their own app bundles into. So the place meant for private, legally obtained binaries sits inside the checkout, and the platform guidance notes that the directory can only be written to after the emulator has been run at least once, because it is created on first run. There is also a second pair of option files, one named as the default and one without that qualifier, alongside a help text file, a `vendor/` directory, a `build.rs`, and both `AGENTS.md` and `CLAUDE.md` at the root.

Editorial conclusion

touchHLE fits someone with a legally obtained, already decrypted copy of an early iOS game and an appetite for reimplementing frameworks. Treat the compatibility database as a lead rather than a list, because the README warns it may be stale and because the majority of apps for those OS versions are stated not to work. Expect UIKit to be the part that is missing when something renders wrongly, since the project names it as the least complete of the large frameworks for the reason that no contributor needed more of it. Check your architecture against the three that have binary releases before building anything yourself. And take the disclaimer seriously: the tool takes an already decrypted binary, ships nothing, and is not affiliated with Apple, so the only thing it needs from you is a copy you already had the right to make.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. touchHLE/touchHLE on GitHub