Diablo II: Resurrected on iPhone: D2R Mobile status

Looking for the current player route? Start with device and signing requirements, then follow the complete v1.0.15 play guide. This page retains the project’s versioned research history.

D2R Mobile provides a local, offline route for a specific Switch release of Diablo II: Resurrected on Apple devices. Its public code combines static program rewriting, platform services, graphics translation, and a touch interface. If your goal is Battle.net multiplayer, this route does not meet it: the project’s online services are deliberately unavailable.

The detailed technical assessment is pinned to v1.0.10, commit 2e7177c08048ebf9335fea102cbd1357eaf92832, checked on 14 October 2026. SwitchToAny inspected the public material; we have not built the game or tested a device.

Project downloads and installation instructions

Looking for a download? Start with the developer’s release notes. The project offers source code, tools, and shells without game content. It does not offer a complete game download. You still need your own required Switch game files, a preparation computer, and a signing/install route.

• D2R Mobile project on GitHub: the upstream source, project overview, and documentation. This is an independent project, not a Blizzard mobile release.
• v1.0.15 release notes and shell downloads: D2RMobile-shell-build-input.zip is for iOS 26 and later; D2RMobile-shell-ios18-build-input.zip is for iOS 18–25. The release also provides SHA256SUMS.txt; source archives are separate. Read the notes before selecting a file.
• v1.0.15 no-Xcode packaging instructions: how the shell route uses your own files, plus its signing and installation limits. For the full Xcode route, start with the same-release project README.
• Required game files: the specific purchased Switch version and expansion expected by the tools. PC files are not interchangeable with these inputs.

Keep the shell and source on the same release, and replace the shell for v1.0.15. The rewriter remains r44, but these fixes are in the app: an older shell does not gain them from newer source. Xcode users must update the source and rebuild. v1.0.15 was published on 14 October 2026 at 20:32 UTC, from commit b94670c795e28742abe1a9cadd64a234a77260ab, and was GitHub’s latest release at our 21:07 UTC check. Use the release list to check for later updates. The release updates below are separately scoped; the detailed assessment below remains pinned to v1.0.10.

If you are not sure which files or route you need, read the device, computer, and signing checklist first.

What changed in v1.0.15?

The release notes report startup checks for incomplete or mixed-release packages and devices without Metal 3. Re-signed packages with no resources bypass the background-assets service and show the resource-import page; resources are checked once immediately before the game starts.

• Graphics translation now runs on its own thread. On the maintainer’s iPhone 17 Pro Max in the same Greater Rift scene, median dropped frames per 300 fell from 85 to 56. Heavy scenes still drop frames; normal-play median was 0. These scene-specific upstream measurements do not establish performance on other devices.
• Leaving the app with the pause menu open now briefly advances the game to save, then restores pause; Mac quitting uses the same path. This is a reported fix, not our save-recovery test.
• Wide-iPhone inventory tooltips and Chronicle reward-page click-through were also fixed.

The maintainer reports fresh builds and packaging with both shells, host builds, unit tests, four Mac smoke runs and older-API Mac game entry. The launch self-check was tested on an iPhone before merge. This does not establish that both exact public v1.0.15 shells were installed and tested on iPhone through a sideloading tool. The same-release no-Xcode guide still marks sideloading-tool signing/installation and Linux packaging unverified. SwitchToAny has not reproduced game, device or save tests.

Device boundary in v1.0.15: the release README now requires A14 / M1 or later, alongside the memory and OS requirements. A13 and earlier, including the 2020 A12Z iPad Pro, are unsupported; 4 GB RAM devices remain unsupported, and A14 devices with at least 6 GB have no reports yet. Do not read “A16 and earlier” in the older snapshot below as support for every older chip. The maintainer’s issue #41 update confirms the Metal 3 startup guard shipped in v1.0.15; libdeflate was not changed. This is release documentation and a maintainer report, not our device test.

The ZIP shell is build input, not installable. The maintainer’s issue #40 update confirms the renamed ZIP and startup self-check shipped in v1.0.15. Generate the install package with matching source and your own required files, then sign/install that output. Repeat packaging for every release; the 18 resource archives already on the phone do not need copying again.

What changed in v1.0.14?

The release notes report these app fixes; SwitchToAny has not independently measured them:

• NPC speech: the app now downmixes 5.1 audio to stereo so the dialogue centre channel is retained.
• Memory: the maintainer reports about 0.5 GB less memory held by making graphics pools resident only when first used. Devices with 4 GB RAM remain unsupported. This is not a new tested-device list.
• Mac: audio output is restored, and the in-game picture fills 16:10 windows/screens. The main menu and character selection remain 16:9. See the same-release Mac guide; these display changes do not add iCloud sync to self-built Mac apps.

The maintainer reports fresh builds of both public shells and their install packages, minimum iOS 18.0 and no Metal 4 symbols for the older-system package, host builds, unit tests, Mac smoke checks and unattended game entry on the older-API Mac app. This is not a report that the two public v1.0.14 shells were installed on an iPhone. SwitchToAny has not reproduced these checks or tested save recovery.

What changed in v1.0.12–v1.0.13?

The v1.0.13 release report describes fixes for iCloud save conflicts after devices have played offline. iCloud sync requires a package signed with a paid developer account and the required iCloud entitlement. This does not add sync to free-account packages. When both devices have different, non-empty shared stashes, the cloud copy becomes current and the local copy is preserved on that device for a later merge. The report explicitly leaves in-game merging as a next step: preserving both copies is not an immediate automatic merge. A new device also waits for cloud visibility or network reachability before its first sync; same-name character conflicts preserve the local copy in a backup.

Other reported changes are narrower than a new compatibility claim:

• v1.0.13 moves system notices away from life/mana numbers and inventory cells, and removes map-preset monsters from Greater Rifts at level 90 and above. Map-placed super uniques, doors, walls, traps, and NPCs remain.
• The preceding v1.0.12 release introduced special elites from Rift level 75 and Guardian waves from level 95. It also clarified installation progress and diagnostics for builds using Apple-hosted resource packs. Its optional direct-download fallback needs a configured address; a package built from the public repository has none.
• v1.0.13 adds the Network framework to the Mac build, but an app you build yourself still has no iCloud save sync. The same-release Mac guide retains local saves and manual import. See the same-release README for signing scope.

For v1.0.13, the maintainer reports building both shells in a fresh public-source workspace with the free-account option, then producing an install package from each using that same source and another fresh workspace. The iOS 18 shell and its package report a minimum OS of 18.0 and no Metal 4 symbols. The report also lists host builds, unit tests including iCloud cases, Mac smoke checks, and an older-API Mac app reaching a game unattended. These are maintainer-reported build and automated checks, not a report that the two public v1.0.13 shells were installed on an iPhone. SwitchToAny has not reproduced them or tested save recovery.

Start with the kind of play you want

The project targets the Switch release 1.0.34.0, including the Reign of the Warlock expansion. Its tools refer to the corresponding PC version number, 3.3.94012. These are identifiers for the supported inputs, rather than interchangeable labels for any copy of D2R. The default tooling checks this version; reports about adaptations of other builds do not extend that default scope. See the pinned project overview.

With this route, the game program runs on the Apple device. A streaming setup instead runs the game on a host computer and sends its picture and controls across a network. Those choices have different prerequisites. An online character or multiplayer requirement is a reason to stop investigating this local route and assess a route that preserves the supported game’s online environment.

Even within offline play, this project makes deliberate changes. Its overview describes touch controls, interface adaptations, and additional gameplay features. If you want an unchanged experience, read those choices before investing in setup. A familiar title screen is not a complete description of the software you will be running.

What is actually available?

The public repository contains the host, rewriting tools, graphics layer, iOS shell, and verification tooling. The principal documented iPhone/iPad route builds the application with Xcode on an Apple silicon Mac, using your own required game files. There is also a macOS application route. These are project-specific workflows, not an App Store release or a general-purpose Switch game converter.

The alternative no-Xcode route starts with a prebuilt shell and adds the user’s game content on a computer. The shell alone cannot run the game. The source and shell must match, and the output still needs signing and installation. The no-Xcode documentation is unusually useful because it separates the stages:

• The maintainer reports Windows 11 packaging and subsequent gameplay on an iPhone, using a package that was signed on a Mac.
• Signing and installation through common sideloading tools remain unverified in that snapshot.
• Linux packaging and setting up a completely fresh Windows dependency environment are also unverified.

This gives a Windows user a documented packaging option, with a remaining installation question. It does not establish an entirely Windows-only, independently reproduced journey.

Read the release evidence at the right level

The v1.0.10 release notes distinguish the published shell artifacts from a test-group build made from the same source. The maintainer reports phone launch, menu, and in-game smoke checks for that test build; the two exact published shells were packaged but not themselves installed in that report.

That distinction matters when deciding what to try. A smoke check of a build from the same source supports a narrower conclusion than installing the actual artifact through your chosen signing route. Likewise, reaching gameplay does not establish long-session stability, performance on another device, or recovery of your existing saves.

The repository’s verification guide documents instruction-equivalence checks, unit tests, and broader acceptance gates. Some full acceptance inputs, including reference run data and standard saves, are not supplied publicly. Their absence limits what an independent reader can reproduce from the repository alone. The existence of a test script does not tell us that every relevant run passed.

Why this does not establish “any Switch game”

The implementation is valuable partly because its assumptions are inspectable. The architecture guide describes rewriting rules and host features tied to this game’s build. Graphics translation also uses game-specific information. Extending the approach means addressing another game’s operating-system calls, graphics behavior, assets, and version-specific assumptions.

We have not established a separately released general converter under the candidate names AnySwitch or Switch2Apple. Those names do not justify a download page, launch date, or compatibility list. The mechanism guide explains where reusable ideas end and additional engineering begins.

A related, separately maintained project provides a concrete reuse example: seedds/smbw-mobile. Its README identifies reuse of D2R Mobile’s generic parts, corroborated by D2R’s issue #36 and v1.0.14 fix. It reports an 11-minute iPhone session through several Super Mario Bros. Wonder levels. The 14 October, 19:49 UTC revision advances Fire Emblem Engage beyond the earlier save-screen-only script: scripted Mac input plays the prologue battle, including player and enemy phases, combat animations, game over and retry; 12-minute runs end without a crash. Follow-up commits on 14 October at 21:40 UTC and 22:34 UTC report further texture-cache cleanup: the author’s 850-second idle demo stayed at 1.2–1.4 GB of GPU memory, with later quiet-point readings of 1.06–1.12 GB; some finalized pool buffers remained retained. Those earlier checks were Mac-side author reports, alongside successful iOS compilation.

The 15 October, 03:00 UTC README revision now reports an initial Engage iPhone run reaching the opening movie and name entry on 15 October without crashing. After returning from the background, one audio output stopped being fed; this remains under investigation. The current profile targets the game’s native 30 fps because forcing 60 fps accelerates player and NPC movement; the corresponding gameplay correction is not ported. The earlier opening test’s reported 60 fps is not a recommendation to force that setting.

Exact iPhone model, OS and signing method are unspecified. iPhone battle gameplay, save/reopen testing and long-session stability are not established by this report. The existing Mac battle evidence must not be presented as an iPhone result. These are the project author’s reports, not our tests or a general compatibility list. Game-specific profiles and known gaps remain; this does not establish an AnySwitch or Switch2Apple release.

A sensible next step

If offline play suits you, check the prerequisites before choosing a build route. Record your exact device, OS, game build, project release, and signing method. That combination is more useful than a broad “works on iPhone” claim.

For code reuse, read the dependency disclosure: the root MIT license does not settle every component’s provenance or license, and seven offline rewrites have unknown original provenance and license. Technical feasibility, permission to reuse materials, and distribution eligibility need separate consideration.

SwitchToAny is independent of the project and platform owners. Our evidence method explains how we distinguish source inspection, maintainer reports, and our own tests.