It replaces early iOS frameworks instead of booting iOS
touchHLE takes a high-level emulation approach. It does not simulate an iPhone and boot Apple's operating system. The project supplies its own implementations of Foundation, UIKit, OpenGL ES, OpenAL, and other pieces, then runs the original app binary plus a small set of libraries. That choice avoids needing a complete iOS image and lets contributors add only the behavior a supported game needs. It also explains why compatibility advances one application and one missing API at a time.
The current target is software made for iPhone OS 2.x, iPhone OS 3.x, and iOS 4.0.x. Version 0.3.0 added iPad mode at 768 by 1024 pixels, support for iPhone OS 3.2.x and iOS 4.0.x apps, and a list of newly working games. The project explicitly rules out 64-bit iOS. Retina displays and later releases through iOS 6 are longer-term aspirations, not current support.
Most apps still do not work, even inside the stated range
The README gives the warning a buyer needs: the vast majority of apps from the supported operating-system generations do not work. Games receive priority, while general applications do not. UIKit remains incomplete because supported games use only parts of it. OpenGL ES and OpenAL cover more ground because early games depend on them heavily. The compatibility database is therefore the first stop. Check the exact app version rather than assuming that a familiar title or operating-system number is enough.
Supported does not mean flawless. Open issue 508 reports a misplaced star animation in Cut the Rope 1.5 on Android 11. Issue 552 reports corrupted Real Racing 1.00 save data on Android 12, including failures after returning to the menu. Those are user reports from particular versions and devices, not universal results. They show the right evaluation method: preserve a copy of your save, test the exact build, and judge the game you care about.
What happened when we ran it
Our sandbox checked commit 8eb3418 in an unprivileged container with 3 CPUs and 12 GB of RAM. Installing 97 Rust packages succeeded in 21 seconds. The build ran for 149 seconds and exited 101. CMake reported that it could not find Boost_INCLUDE_DIR and required Boost 1.57 or newer. The Rust CMake wrapper then stopped because its command returned status 1. That is the failure shown by the log.
The test command failed with exit 101 after 10 seconds at the same build stage. Its tail again says Boost's include directory was missing, followed by the CMake wrapper panic. The run produced no passed or failed test-case count because the test binary did not finish building. The 20.2 MB checkout contained 408 files and roughly 78,778 lines of source. It had one CI workflow and a tests directory, but no Dockerfile.
Boost is documented, but it is outside Cargo
The source build is more than cargo build. The guide requires Git submodules, a Rust toolchain, CMake, C and C++ compilers, and Boost. On Windows hosts or Android targets, Boost is unpacked into vendor/boost; other operating systems must install it through their package manager. Our base Rust image supplied enough tooling to install 97 packages, yet it did not supply the Boost headers that the native dependency expected. The failure is a setup finding, not evidence that the emulator itself crashes.
Linux is also outside the project's regularly tested binary path. Official downloads cover x64 Windows, x64 macOS, and AArch64 Android. AArch64 and x64 Linux are expected to work when built locally, but the building guide says those combinations are not regularly tested. Android requires its Rust target, cargo-ndk 3.4.0 or later, and the Android SDK and NDK. Downloading a release is the sensible first trial unless source work is the point.
You must bring a decrypted app that you obtained legally
touchHLE does not include Apple software or old games. The app binary must already be decrypted, and the project tells users to emulate only software obtained legally. On desktops, .ipa files or .app bundles can go beside the executable or in the app-picker directory. Android confines them to the application's storage area, where newer scoped-storage rules can make file management awkward. Saved games live in a separate touchHLE_sandbox directory.
Input support is thoughtful for software designed around a touchscreen and accelerometer. A mouse can tap or simulate tilt, a controller can drive a virtual cursor, and buttons can map to screen coordinates. Devices with touchscreens or accelerometers can use their physical inputs. Local Wi-Fi multiplayer currently names 2 supported games, Asphalt 4 and N.O.V.A.; Internet tunneling is unsupported and Bluetooth is unavailable. Those limits matter if preservation includes the original multiplayer experience.
v0.3.0 is fresh, and contribution rules are unusually strict
GitHub showed 3,957 stars and 98 open issues and pull requests on October 2, 2026. The API split that total into 88 issues and 10 pull requests. Both v0.3.0 and the last repository push landed on October 1. The release added more than 20 working titles, iPad support, early iOS 4 compatibility, new dynamic libraries, and coroutine-based threading after a long-running deadlock problem. This is active preservation work, despite the small version number.
Patches go through GerritHub rather than ordinary GitHub pull requests, and the project requires code review plus local verification. Its clean-room rules prohibit leaked Apple material, decompilation of Apple components, and AI-generated contributions because their training sources cannot be audited. Source is MPL 2.0, release binaries are GPL 3 or later, and bundled libraries and fonts have their own terms. For players, start with the compatibility database and a v0.3.0 binary. For builders, our missing-Boost failure is the reminder to read the host prerequisites before Cargo.