Why ARM64 alone cannot make a Switch game run on iPhone

ARM64 tells you what instructions a CPU understands. It does not tell you which operating-system services exist, how graphics commands reach a GPU, or which executable code a phone will load. D2R Mobile, a compatibility layer for Diablo II: Resurrected, is a useful case study because its public implementation addresses all of those layers for one particular game build.

The explanation here follows v1.0.10, commit 2e7177c08048ebf9335fea102cbd1357eaf92832, checked on 14 October 2026. This is a source-based explanation, not a performance test or a claim about arbitrary Switch games.

1. The CPU can understand an instruction and still need different behavior

Much of this game’s ARM64 program can execute directly on the Apple CPU. The difficulty is the platform context around it. A register may have a platform-specific role; an instruction may request a service from a kernel that is absent on the destination system.

The project’s rewriting architecture describes rewriting uses of x18, thread-local-storage registers, system calls, and timer reads. Thread-related values move into storage managed by the host. System calls go through a host entry point that supplies the expected behavior. Timer reads get the time representation the guest program expects.

This happens ahead of execution. The rewriter also contains game-build-specific changes, with original-byte checks that stop a rewrite if its assumptions do not match the input. That is a useful safety property, and a reason why changing the input game version is consequential. Instructions at a known address in one build need not mean the same thing in the next.

2. The host supplies the world around the program

A running game needs threads, synchronization, memory, files, input, audio, and platform services. Rewriting a system-call instruction only gets the request to the right place; something still has to answer it correctly.

D2R Mobile’s host maps modules into memory, resolves imports, initializes the runtime, and supplies implementations for those services. Some suitable C library calls can connect to Apple’s libraries. Other calls need custom host behavior. The host overview describes several ways of intercepting these requests rather than one universal translation rule.

This layer also explains a practical limitation: the project’s online-related interfaces return unavailable responses. Local CPU execution cannot conjure a compatible account, matchmaking, or multiplayer service. Whether the game boots and whether it meets your intended mode of play are separate questions.

3. The GPU has a different program to run

The CPU instruction set says little about graphics compatibility. This game’s graphics calls use NVN, while Apple’s graphics API is Metal. The project takes over NVN function lookup, records commands, then replays them through Metal. Textures also need their layouts and formats handled correctly.

The shader programs are a second translation problem. The graphics guide describes the chain from original Maxwell GPU code through SPIR-V to Metal Shading Language, then to a Metal library. Four embedded compute shaders instead have hand-written MSL. On the no-Xcode route, the final Metal compilation happens on the phone; the earlier translation still happens on the preparation computer.

Translation sometimes needs information that cannot be recovered from shader machine code alone. This project includes a facts table originally generated from paired PC shader reflection. The table generator makes an important distinction: normal builds read the supplied table without PC game files; regenerating or checking it requires additional PC-side inputs. Another game may not offer the same pairing.

At this snapshot, the graphics documentation counts 523 looked-up NVN names: 203 semantic implementations, 13 empty implementations, and 307 reporting stubs. These figures describe engineering coverage for this codebase. Dividing them into a percentage would not produce a game compatibility score: functions differ in importance, and another game can call different ones.

4. iOS must be able to load the resulting code

Apple’s runtime security documentation describes restrictions on writable executable memory, together with app sandboxing and entitlements. A shared instruction set does not remove those platform rules.

D2R Mobile prepares rewritten CPU code ahead of time and packages it as signed executable code. The main iOS source-build route embeds rewritten modules into the application; the embedding generator and loader implement this arrangement. The game CPU program is not being continually recompiled by a JIT as it runs.

That reduces one kind of runtime requirement. It does not remove signing, provisioning, installation, or OS-version requirements. On-device Metal shader compilation is also distinct from a JIT translating the game’s CPU instructions. Treating both as simply “compiling on the phone” obscures which restrictions and tools matter.

What would another game need?

At minimum, an extension would need to establish its input version, identify platform-sensitive instructions, cover the services it uses, translate its graphics and shaders, and remove assumptions tied to D2R’s addresses or data. Then it would need evidence across startup, actual gameplay, input, and saves.

The verification tools show how smaller claims can be checked. Instruction equivalence can support a rewrite; it cannot alone prove an entire game’s behavior. Some broader reference inputs are not public, and SwitchToAny has not independently run these tests.

The useful takeaway is a four-part question: can the CPU code run, can its services be supplied, can its graphics be reproduced, and can the resulting application be installed correctly? Check your D2R prerequisites if you want to try the documented route, or read the project status before interpreting a new demonstration.