Dynamic binary instrumentation inserts probes into an executing program. On desktop systems, a framework decodes instructions, emits modified machine code into writable-executable memory, and jumps to the translated block. iOS forbids unsigned executable code and restricts writable-plus-executable pages, removing the normal JIT path.
Jailbreak-based injection bypasses the sandbox but trails current operating-system releases and changes the environment under study. App repackaging can inject a library after resigning, yet usually hooks APIs rather than arbitrary instructions and lets software detect that its binary changed. Full emulation avoids those constraints but duplicates iOS’s multi-gigabyte dynamic-library shared cache on a device with limited RAM.
iLand runs as a normally signed sandboxed app and emulates another app at instruction granularity. It never generates executable code. The design interprets guest application instructions through a fixed vocabulary of precompiled, signed execution units and lets system frameworks run on the host CPU.
Precompiled micro-operations replace a JIT cache
iLand decodes an Arm64 guest instruction and translates it into one or more micro-operations with equivalent semantics. Each micro-operation dispatches to an atomic execution unit compiled into the iLand binary before signing. Operands and guest state are data, so the runtime writes no new code and requests no RWX mapping.
The interpreter can place a probe before or after any guest instruction, library call, or system call. A plugin reads or modifies registers and memory through the framework. Unlike static rewriting, instrumentation is not constrained by the number of bytes available at the original location and can make a decision using live state.
Interpretation costs more than native execution because each guest instruction becomes decoding, dispatch, and state updates. iLand reduces repeated work with translation metadata and a tight dispatch loop, but cannot approach a JIT’s direct execution of cached blocks. The design trades throughput for conformance with the sandbox.
Application-only emulation keeps the shared cache native
An iPhone 15-class system can map roughly 3.3GB of system libraries while offering 6GB of RAM. Emulating a second copy risks Jetsam, the iOS out-of-memory killer. iLand interprets only instructions belonging to the guest app. Calls into UIKit, networking, codecs, and other system libraries execute natively in the host process’s existing shared cache.
Frequent app-to-library boundaries require state transfer. A conventional emulator might maintain a persistent shadow call stack, but callbacks, Objective-C messaging, exceptions, and asynchronous returns make it fragile. iLand’s stateless control-flow manager reconstructs the next domain from addresses and saved guest context rather than assuming perfectly nested crossings.
Native execution explains interactive compatibility. Scrolling, text entry, UI composition, video decode, and much network work occur in optimized system frameworks. The interpreted app logic can be tens of times slower without producing the same visible slowdown on workloads dominated by libraries. CPU-bound code inside the app still pays the full cost.
The boundary is also a coverage limit. Code downloaded as data cannot become executable under the sandbox. Private frameworks, unusual Objective-C runtime behavior, hand-written assembly, signals, and self-checks can expose semantic differences. An analysis must state which instructions ran under interpretation and which code remained native.
Compatibility is substantial but not universal
The researchers tested 64 top free US App Store apps on iOS 16.7.7. Forty-nine completed core functionality such as login, browsing, search, video, and app-specific flows. Gmail supported login and mail browsing; YouTube played video; X, Threads, and Discord retained common interactions.
Eleven apps had functional anomalies and four self-terminated. Some detected or depended on environment behavior; other operations prohibited on real iOS succeeded inside the virtualized model and caused divergence. Compatibility therefore means selected manual flows worked, not that every app path or security property was identical.
Memory overhead ranged with binary size and translated metadata, while the application-only design avoided a second shared cache. Manual testers considered the working apps responsive, but no controlled user-latency study proves indistinguishable interaction. Reproducibility also depends on app versions that change rapidly and may no longer be obtainable from the store.
Compute benchmarks price instruction visibility
SPEC CPU 2017 on an iPhone X compared native execution, Valgrind on supported environments, QEMU variants, and iLand. Valgrind took roughly five to ten times native time; iLand took 15 to 90 times. QEMU’s TCI interpreter was 100 to 600 times slower in the cited comparison, while JIT QEMU cannot satisfy iOS sandbox rules.
The wide iLand range reflects instruction mix, library fraction, and dispatch behavior. A benchmark remaining inside guest code is worst-case. An app spending most time in native frameworks pays less. Instrumentation callbacks add further overhead depending on probe density and analysis complexity.
This profile fits offline security analysis, debugging, tracing, and app review more than continuous consumer deployment. A store operator can run selected flows on dedicated devices and accept minutes of analysis. It would be unsuitable as an always-on performance monitor for CPU-heavy games or cryptography.
Instruction traces reveal paths hidden behind API hooks
The team built a dynamic tracing plugin and evaluated 60 sufficiently usable apps. It recorded embedded SVC instructions, system-call arguments, runtime dlsym, and indirect control transfers into non-imported symbols in the dynamic shared cache. These paths can bypass API-level hooking because an app calls a kernel service directly or resolves a private function at runtime.
Thirteen of the 60 apps invoked private APIs; two used APIs explicitly rejected by Apple policy. Twenty-four binaries contained 2,914 SVC instructions. Fifteen apps invoked filesystem-related system calls to inspect system directories, a pattern that can contribute to device fingerprinting or environment attestation.
The findings do not establish malicious intent. A private syscall can support anti-tampering, compatibility, or performance, and dynamic analysis sees only exercised paths. The paper classifies privacy and robustness risks and argues for scrutiny rather than declaring every invocation a violation.
Coverage depended on manual interaction. Registration, regional content, paid features, delayed triggers, server-side flags, and anti-analysis logic can remain dormant. Automated UI exploration, multiple accounts, and repeated environmental conditions would improve path coverage but still cannot prove absence.
A sandboxed analyzer still handles untrusted code
iLand loads and interprets closed-source app binaries inside its own process. Decoder, loader, Objective-C bridge, syscall mediation, and plugin interfaces become an attack surface. A malformed Mach-O or instruction stream could target the analyzer even if guest code cannot execute directly. Fuzzing and memory-safe parsing are necessary for a store-scale service.
Native system calls must be mediated so a guest app cannot inherit iLand’s container privileges or access the host app’s data. Paths, keychain groups, entitlements, bundle identifiers, and privacy prompts need a virtualized identity matching the guest. Too much permissiveness creates behavior impossible on a real install; too much restriction creates false failures.
Code signing and licensing also matter. An operator needs authority to obtain, decrypt if necessary, and analyze app binaries. Repackaging is avoided, but executing one app within another can still conflict with platform policy. The research prototype demonstrates a technical path, not an App Store-approved distribution model.
Version drift is unavoidable. Arm64 extensions, pointer authentication, memory tagging, Swift runtime changes, and new iOS shared-cache layouts require semantic updates. The no-JIT method reduces one policy dependency but does not make the emulator version-independent.
Practicality comes from selective native execution
iLand’s 15-to-90-times compute overhead looks incompatible with mobile interaction until the execution split is considered. Application control logic is interpreted; expensive standardized services remain native. The system pays for visibility exactly where private app behavior resides and reuses the operating system where behavior is already trusted or not the analysis target.
The 49-of-64 compatibility result establishes breadth, while 15 failures establish that the boundary is not transparent. The policy study shows value unavailable to ordinary API hooks: direct SVC and non-imported private calls. A deployment should present these findings with path coverage and compatibility status rather than a binary safe/unsafe label.
The broader systems lesson is that a prohibition on dynamic code generation does not prohibit dynamic analysis. Precompiled semantic units can turn code into data and restore instruction-level control, at the cost of interpreter performance. Application-only emulation then makes that cost tolerable for analysis by avoiding the system code that dominates memory and user experience.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the architecture, evaluation, findings, and limitations in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX OSDI 2026 presentation page. Copyright remains with the authors, 2026.