How D2R Mobile Works: A Switch Game Running Natively on iPhone
Quick Answer
- The one sentence
- iPhone and Switch use the same processor family — so the game's own program runs directly, with only the handful of instructions that Apple's kernel forbids rewritten.
- Why not an emulator
- There is no emulated CPU anywhere in the loop. That is the entire reason for 60 fps and a 3.8 W power draw on a phone.
- Why you can trust it
- The project ships verification tooling: unit tests, per-instruction equivalence checks, scripted regressions — and a 44-device beta that cleared the game on every model.
The Core Idea: Same Processor, Same Program
The popular description — "it runs a Switch game on your iPhone" — sounds like magic until you meet the actual premise: iPhone and Switch use the same class of processor (both are aarch64). The game's real, shipped program can therefore execute on your device almost as-is. What it cannot do is talk to Apple's kernel, because it was built to talk to Nintendo's.
So the project does two things, and nothing more than it must:
- Rewrite the few instructions that Apple's kernel forbids — offline, once, with every rewrite checked;
- Provide a host — a small program that answers the game's calls the way the Switch's operating system would.
Everything else — every class, every skill tree, every Runeword, every drop rule — is the original program's own code, untouched.
What Actually Gets Rewritten
Four classes of instructions, documented publicly in the project's repository. Each entry: what the original does, why it cannot run as-is, and what it becomes instead.
| Original instruction | Why it cannot run as-is | What it becomes |
|---|---|---|
x18 register reads and writes | The Apple kernel keeps its own data in this register | A per-thread storage slot |
tpidr_el0 access | The game uses it to find thread-local storage the way the Switch OS arranges it — a layout Apple's platforms do not have | The same thread-slot mechanism |
svc (system calls) | There is no Switch kernel on an iPhone to call | A jump to the "host gate" — an entry point into the host program's C code |
cntpct_el0 (the system counter) | The Switch's timer hardware does not exist on Apple devices | Also through the host gate — the host answers as a 19.2 MHz counter |
That is the entire list. The rewrite is verified mechanically: every changed site is checked before writing (original bytes compared entry by entry), and the project's regress tooling re-runs a before/after equivalence trial of each rewritten instruction on an emulated CPU to prove behavior matches. When we say "byte-for-byte the original except for a few instructions," this tooling is what makes it checkable rather than a claim.
The Host: Replacing the Switch Operating System
The host is where the engineering lives. The game's dependence on its platform comes in three layers, and the host answers each differently:
- Kernel calls. Rewritten system calls are routed by address to host implementations: memory management, threads, locks, events. The Switch SDK's own
nn::oslayer above those calls runs unchanged — only the kernel underneath is replaced. - C library functions. Where the calling conventions line up, calls connect directly to Apple's own libc.
- System services. Files, audio, controller and touch input, the on-screen keyboard — services that run as separate processes on a real console — are taken over function by function and implemented by the host. (Character names can be typed in Chinese, a small hint at the project's origins.)
Anything not implemented gets a named stub that logs one line and returns zero, rather than silently misbehaving. And online features — multiplayer, friends, the shop — uniformly answer "unavailable," which sends the game down its own offline branch. That is a design decision, not a gap: the port is deliberately, fully offline.
Graphics: From the Switch's API to Metal
The game draws through NVN, the Switch's graphics interface. The host forcibly takes over the single entry point the game uses to obtain graphics functions — meaning not one instruction of the console's graphics driver executes. Instead, the game's graphics calls are recorded and replayed as Apple Metal calls by a purpose-built layer.
The shaders are the deeper trick: they are not hand-written. The game's original shaders are translated offline into native Metal shader libraries at build time, ahead of anything running — so entering a new scene never stalls to compile anything. The translation chain builds on Ryujinx's open-source shader translator (converted through SPIR-V), and all 7,212 shaders are compiled once, up front.
Why You Can Trust It
Stability at this depth is not luck — the project treats verification as a feature:
| Layer | What is verified |
|---|---|
| Rewriter | Every rewritten site: original bytes checked before writing; before/after equivalence trials on an emulated CPU |
| Host & graphics | Unit tests for both layers, run in the project's own CI |
| Interface | Scripted walkthrough regressions of the touch UI, plus on-device smoke tests |
| Builds | Packages built on Windows vs. Mac compared file by file: 14,017 files byte-identical (only sub-pixel label-image differences remain) |
| Real devices | A 44-device closed beta — every device cleared Normal, Nightmare and Hell |
For contrast: most fan projects at this level ship a demo that "sort of runs." This one documents not just what works but what is not yet verified — a habit that says more than any benchmark.
What This Means for You
- The performance floor is the silicon's — no emulation overhead, no translation layer in the hot path. That is why a phone holds 60 fps at ~3.8 W: nearly 5 hours of play on a full charge.
- The game inside is really the game. Because it is the original program, behavior, breakpoints and bugs match the console release — for better and (rarely) for worse.
- The same approach scales sideways. The project already ships a native Mac app; it documents that the Android route is technically open (same processor family again) and publicly welcomes a port. Its own README lists this as an invitation.
Technical FAQ
So is it an emulator or not?
Not in the way the word is used: no CPU is being emulated, and the game's program executes directly on your device's processor. The project prefers "compatibility layer" — a host that speaks the Switch operating system's language to a program that was written to expect it.
Why do I have to supply the game files instead of downloading them?
Because the repository is engineering, not distribution: it contains the rewriter, the host, and the graphics layer — and no game content, by design and by policy. Your own Switch copy provides the program and data; the tools convert them on your machine. This is also what keeps the project's legal position defensible.
Will this work for other Switch games?
Parts of it, in principle — the project documents which host behaviors are tuned specifically to D2R and would need to be turned off first. But a general-purpose Switch compatibility layer is a much larger project; this one is deliberately deep on a single game rather than shallow on many.
Architecture details from the d2r-mobile repository's engineering documentation (README and dm/ documentation, accessed 2026-10-16): instruction rewrite table, host layering, graphics pipeline, and verification tooling. The "why you can trust it" and "what this means" framings are ours, built on those documented facts.