Research archive: D2R Mobile, nxnative & SwitchWaker

v1.0.18 released: rebuild with the matching source and shell

D2R Mobile v1.0.18 was published on 17 October at 13:11:59 UTC, tag 120fe55. It includes the redesigned touch controls (#74), native-size iPhone window (#73), Mac mouse changes (#65), Guest signing space for LiveContainer (#76), minimap UI-rebuild/input-switch correction (#64), Nintendo face-button mapping, Mac reflection-file copying, and rendering/loading fixes. Earlier “source only / no new shell” checkpoints below are historical. The separate NPC Act-travel path in #61 is not established as fixed, and there is still no supported Apple TV installation route here.

Upgrade means remaking the package, even though the rewriter remains r44. Use v1.0.18 source with its matching shell and redo d2rm_pack.py step 1, then sign/install the resulting package. The resource archives already on the phone stay in place; this is not an instruction to delete the app or resources. Back up saves independently first. Xcode users update source and rebuild; this guide pins the release tag rather than a moving main branch. The two ZIPs remain build inputs, not installable apps: default for iOS 26+, older-API for iOS 18–25. SHA256SUMS.txt is now a third release asset; source archives are separate.

Maintainer-reported checks: host/graphics/iOS tests and full host checks; iPhone 17 Pro Max smoke checks (three game launches per iOS-app change, plus in-game/pause-menu checks) and Mac runs; byte-identical rewriter outputs; fresh-workspace shell packaging; Apple codesign and AltSign/ldid signature/page-hash checks. The release reports LiveContainer signing/startup support, but does not identify a separate exact LiveContainer app version/device session. The ldid checks are not end-to-end AltStore installation, and the release notes say Sideloadly remains untested. SwitchToAny has not built or run the game or tested these packages. Short smoke checks do not establish broad compatibility, performance, save recovery or long-session stability. The 4 GB memory limits and A12Z research boundary remain.

Signing-source qualification: in an 11:31:37 UTC author reply, Joe says Sideloadly worked in a test and AltStore signing is normal after PR #76. The later 13:11:59 UTC v1.0.18 release notes still list the Sideloadly signer as untested. The post gives no device/OS, tool version or complete installation/startup session. We retain both dated statements rather than treating the earlier brief reply as end-to-end validation or assuming either source is wrong; the release’s narrower checks and this guide’s installation limits still apply.

Current platform overview

• iPhone / iPad: a documented, offline v1.0.18 build-and-sign route using your own matching game inputs. Check chip, RAM, OS and signing limits before preparing; this is not all-device compatibility.
• Apple silicon Mac: a native local-build route, with local ad-hoc signing and no iCloud sync in self-built apps. It remains subject to the documented build and device limits.
• Android: two separate community projects: dodola, with no public APK at review and build 91738 inputs; and sydeEvans v0.6.1, with public APK/kit metadata but unfinished fresh-import validation and different preparation requirements. Neither is an official upstream Android release or a SwitchToAny device test.

Version scope: v1.0.18 is the current Apple release covered here. v1.0.10 labels the retained historical technical assessment, not the latest release or the Android fork. None of these entries is a SwitchToAny device test.

v1.0.18 is the current release. Use same-release source and shell and redo packaging step 1; existing phone resource archives can stay. Back up the entire save folder outside the app container first. v1.0.18 inherits the v1.0.17 stash hotfix; v1.0.16 remains withdrawn, and earlier lost or duplicated items are not restored or cleaned up. Personal-stash defects are not limited to iCloud users. These are maintainer reports, not a SwitchToAny recovery guarantee. Release and verification scope

Looking for the current player route? Start with device and signing requirements, then follow the complete v1.0.18 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.

4 GB: a brief iPad mini 6 report, with severe memory pressure

The 12:26 UTC README update on 17 October replaces the categorical 4 GB exclusion on main with a maintainer-relayed player report: iPad mini 6 / A15 / 4 GB / iPadOS 27, using the Legacy Device Pack, ran a few minutes of Act I at 50–58 fps after automatic quality reduction. It had constant system memory warnings and only about 560 MB of headroom below the system memory limit. The maintainer warns that busier scenes may be terminated by the system; that is a risk, not an observed termination in this particular run.

The exact tested project build, signing method, test date, save/reopen results and sustained stability are unspecified. The 12:26 commit was a README-only change; its source became the v1.0.18 tag at 13:11:59. Neither note supplies the exact build used in that short player run or verifies sustained 4 GB stability. The earlier iPad Air 4 startup failure remains historical; the mini 6 report does not establish that model’s compatibility. 4 GB is therefore a high-risk experimental case, not permanently impossible and not a stable route established by SwitchToAny. The version-pinned guide and selector still stop short of recommending a 4 GB installation; their routing rules are unchanged.

A12Z: proposal under review, outside the released v1.0.18 route

On 17 October at 07:52 UTC, the maintainer withdrew the earlier categorical A12Z conclusion after checking a community per-slot-binding proposal against the source. A contributor reports roughly 60 FPS with substantial heat, without a pinned source build, OS or session duration. The maintainer has no A12Z and requests a PR plus evidence before main integration: unchanged existing Metal 3 shader outputs (except the chain field), A12Z boot logs and town/field/fire screenshots, frame-rate/thermal diagnostics, a separate roughly 170 MB shader tier in the Legacy Device Pack, and at least 6 GB physical RAM. A 30 FPS thermal comparison is also requested if possible.

No related public PR, merge or release was present at this check. The v1.0.18 tag still excludes this proposal and retains the A14/M1 minimum. This is a source-reviewed research path, not an available installation method or a SwitchToAny compatibility test. The proposed renderer/shader changes are not the existing texture pack or a re-signing workaround; no third-party IPA is recommended. The issue’s earlier closure does not establish delivery.

Android: dodola’s experimental community fork

The dodola Android fork, reviewed on 16 October 2026 at commit 642480b, is separate from the upstream Apple release. It uses an ARM64 host and Vulkan. The author reports device runs on ROD-W09 / Mali-G610 MC6 and PPG-AN00 / Adreno 830. Branch-level checks cover character selection, town, touch controls, inventory/settings, basic melee, Act I camp–wilderness travel, and save/exit followed by a cold restart. The report does not map every check to each device. These are author reports, not SwitchToAny tests or full-game compatibility.

No public APK or complete fresh-clone build/install route is available in the reviewed fork. Some helper scripts are public, but preparation still depends on an unpublished base APK and generated inputs, plus matching game modules, drivers and shader cache. Installing an arbitrary APK or following the Apple shell instructions does not resolve those prerequisites. Use only game inputs you may lawfully prepare; this site supplies no game files or installation package.

The reviewed dodola fork targets build 91738. Do not reuse this site’s Apple 94012 / 1.0.34.0 game-input instructions. The upstream-sync report says that merging v1.0.17 source history does not automatically enable its build-dependent personal-stash/iCloud modules on Android 91738. Keep independent backups; limited save/cold-start checks do not establish long-term save safety. There is no verified Android RAM minimum or broad supported-device list here. Full progression, major fights, other scene transitions and long sessions remain unverified.

The latest Vulkan experiment measured a specific 30 Hz town scenario, not universal 60 fps. The author’s short Android demonstration uses other conditions; neither establishes sustained performance on your device. For now, review the fork’s evidence and wait for a reproducible installation route rather than applying this site’s Apple route selector.

Android: separate sydeEvans v0.6.1 community release

18 October, 00:15:02 UTC: v0.6.1 publishes a new APK and computer packaging kit, tagged at 863ff4a. It adds an optional bundled Turnip T30 driver, landscape-rotation handling, rendering-CPU optimizations and abnormal-frame diagnostics. The release body only links its source comparison; the following results come from the maintainer’s commit and progress record, not an independent test of the published APK.

The documented device remains OPPO OPD2409 / SM8750P / Adreno 830, Android 16/API 36, about 12 GB RAM. The author reports the same field scene improving from 45–47 to 60–62 FPS, smooth lighting with Turnip at similar frame rates, both driver selections taking effect, and rotation between landscape orientations retaining the process/run. No session duration or new hardware coverage is given; first-use shader/loading stalls and other long frames remain. These observations do not establish sustained 60 FPS, all-scene stability or general Android support.

The system driver remains the default. Driver notes describe optional Turnip and logging the actual selection: a driver-load failure can fall back to the system driver, whereas a shader subgroup mismatch refuses launch. The tested package requires 64, while this Turnip build’s physical default is 128; choosing a driver alone does not make arbitrary prepared shaders compatible. Turnip metadata requires API 30/Android 11, while the app manifest still declares API 29 and Vulkan 1.1. These are different minimums, not a tested-device promise.

The exact-tag build workflow succeeded, but the older clean-import/update/save reports below are not fresh v0.6.1 acceptance. A fresh device run of the hardened import remains pending. Xiaomi PR #1 is still open and unmerged at the 01:02 UTC check; 863ff4a/v0.6.1 do not contain its controller-axis fix. Keep the preparation, independent-save-backup and signing cautions below. No APK, driver or game file was downloaded or run by SwitchToAny.

18 October, 01:56:36 UTC source follow-up: PR #1 is now merged into main 5d8e322. Source inspection confirms both a fully matching controller source mask and a real stick/d-pad axis are now required, with extra visibility diagnostics. Published v0.6.1 remains 863ff4a and excludes this merge. The older Xiaomi 2510DRK44C/Adreno 830 report used v0.3 plus the patch; merging it adds no new Android OS, duration, full-control, performance or save/reopen validation. The maintainer’s 01:57 reply points to the earlier Turnip update, not a new release containing this fix.

Earlier v0.3 release and retained preparation/save boundaries

The author linked sydeEvans/d2r-android from upstream issue #59 on 17 October at 06:04 UTC. This is a separate project from dodola, not an upstream Apple release or official Android edition. Its v0.3 release, published at 05:06 UTC, lists a generic APK and a PC packaging kit. The tag points to b538fcda; main 8e22959 adds two documentation/screenshot commits, not runtime changes. The project identifies upstream 2eb5758 from 13 October as its source baseline; do not assume it includes later v1.0.17 stash fixes.

An APK alone is not enough. The documented pipeline still needs a computer, your own lawful game files and keys, and packaging tools including Python, hactool and .NET 10. Source-building the APK is documented for Linux x86_64. Its examples use 3.3.94012, unlike dodola’s 91738. It needs the full RomFS data/ directory, including hidden files, generated modules and a device/driver-compatible shader subgroup configuration; the Apple guide’s 18-file copy step is not this Android package. The package documentation explicitly says the pipeline does not validate game version or digests. Successful packaging does not establish correct inputs or device compatibility. The build and manifest declare ARM64, Android API 29+ and Vulkan 1.1 requirements, not a tested-device list.

The author reports about 60 FPS in Act I camp on OPPO OPD2409 / Adreno 830, with first-use shader stalls and other long frames remaining. This does not establish all-scene, combat or long thermal stability. Crucially, the progress record says clean end-to-end import used v0.2, followed by an in-place update; a fresh device run of the hardened roughly 8.9 GB import remains pending. Do not read v0.3’s release or successful CI as a fully verified fresh installation route. A later author report restored one level-1 AndroidProbe character and matched 17/17 backed-up files; this is not long-term save or cross-device compatibility evidence.

Keep an independent exported save backup before changing builds or importing saves. Import replaces the whole save tree; its temporary rollback directory is removed after success, and the manifest disables Android automatic backup. The reviewed build script uses an Android Debug keystore and keeps the app debuggable; no durable release-signing identity or certificate fingerprint is established here. Do not uninstall to bypass an update/signature conflict before protecting your saves. We have not downloaded, run or audited the APK; this is a source/release report, not an installation or safety recommendation. The MIT code license does not grant rights to game assets; no game files or keys are supplied by SwitchToAny.

17 October Xiaomi touch-control report: gbcmikeblue’s 11:35 reply links this symptom to their fork. The 6ac0919 patch reports that 2510DRK44C / Adreno 830 has a uinput-xiaomi virtual input node marked as a gamepad but exposing no axes, hiding the touch controls. It adds an actual stick/D-pad-axis check to the existing full source-mask check. The author says v0.3 plus the patch restores visibility of the joystick and five button groups. sydeEvans PR #1, opened at 11:41 UTC, was open and unmerged at that 17 October checkpoint; main 8e22959 and the published v0.3 did not include it, and the fork has no release. Android version, session duration, full control behavior, performance and save/reopen results are unspecified. The author reports 395 i18n checks passed, but no valid Windows literal-scan result or Android CI run. This is a scoped community report, not our test or an APK recommendation.

v1.0.17 save hotfix

Published on 15 October at 15:28 UTC, tag commit 9de307e. The maintainer reports revised personal-stash page tracking, removal of the incorrect matching-item deletion, and checking all saves when settling iCloud item returns. The release reports 29 scripted Mac kill/restart runs, merge interruption tests, host/unit checks and three Mac smoke runs. Both shells produced complete packages; this is not proof of installation of those exact public shells on an iPhone. We have not reproduced the tests.

The same-release packaging guide retains the two ZIP build inputs, OS split and unchanged r44. Redo packaging with matching source; existing resource archives can remain. Sideloading-tool signing/installation remains unverified. v1.0.17 includes v1.0.16’s other changes, but no Apple TV package.

After v1.0.17: source changes and reported issues

Historical source checkpoints below: these changes were subsequently included in v1.0.18. The original dates and test limits are retained.

17 October public-source export: unchanged v1.0.17 release

09:47 UTC: public commit 46cb318 exports the previously reported Nintendo direct-letter mapping, PR #64’s minimap UI-rebuild/mode-switch correction, #55’s scanner prefilter and #56’s tvOS changes, alongside the new #74 touch appearance/layout. This supersedes the earlier pending-export checkpoints below. The published v1.0.17 tag and shells remain unchanged. Public code availability is not a new package or SwitchToAny device validation. The #64 path still does not establish resolution of #61’s separate NPC Act-travel path; tvOS save/control/long-session limits remain.

PR #74 was closed without a GitHub merge, then exported from the internal branch; 6edec84 at 10:05 UTC adds the brighter empty-slot rim. The owner’s earlier internal-build report covers iPhone 17 Pro Max smoke checks plus a 35-second in-game/pause-menu path, not a long play session or iPad validation. The final rim/512px contributor follow-up reports host/layout checks and a synthetic preview, explicitly no new device build/install/test. Those earlier runtime results do not validate this final follow-up. The guide now follows v1.0.18; its release-level maintainer checks are recorded separately above.

At the 16:51 UTC checkpoint on 16 October, PR #67 added a legacy CommitSaveData forced entry in dc53e7a. The maintainer said D2R itself uses only Commit, so it was not a new D2R save fix. Host tests through both entries passed according to the contributor; gameplay, iOS integration and the full asset-dependent suite were not run. That addition was subsequently found to abort the supported game’s startup and was reverted in #73 below. It is historical, not the current source behavior.

• Solid pink-purple Mac picture, with audio still working: in issue #60, the maintainer traced the reported CI-built app failure to missing shader reflection JSON files. A shell glob for about 6,900 files exceeded the argument-length limit in a deep workspace path, so none were copied. Main commit 1784563 (15 October, 17:43 UTC) copies by directory and checks each shader library has its reflection. The maintainer reports a 420-character-path check yielding 7,212 libraries and 6,927 reflections. This fix is after the v1.0.17 tag and is included in v1.0.18; it is a Mac-build correction, not a diagnosis of an iOS-shell problem. If your Mac log says 无反射 json (“no reflection json”), compare it with this issue and have the affected Mac package rebuilt with the correction; do not assume every pink screen has this cause. SwitchToAny has not built or tested the fix.
• Nintendo face buttons swapped: on 16 October, 08:53 UTC, the maintainer closed PR #58 as an equivalent fix already adopted. The issue #57 reply says direct letter mapping will ship with the next internal build. Both threads are closed; PR #58 was not merged. At the 09:03 UTC source check, public main still pointed to 1784563 and the cited dc6e0fc6d could not be retrieved through the public GitHub API. At that earlier checkpoint this was a maintainer-reported incorporation, not public-source verification or a released-shell fix; the 17 October public export now changes the source status. v1.0.18 now includes the correction; v1.0.17 does not. The earlier 15 October report describes 18 passing mapping tests, not a completed device smoke test. Single-Joy-Con sideways use remains unverified in these reports.

iPhone fullscreen and startup: included in v1.0.18

On 16 October at 17:35 UTC, PR #73 merged into public main as 21cf97b. It declares UILaunchScreen so iPhone uses a native-size window instead of legacy compatibility borders, and removes #67’s unused CommitSaveData forced entry. The maintainer confirms that supported game 3.3.94012 does not reference that entry, causing the strict loader to abort; the existing transactional Commit and strict loader checks are retained. If a source build from the intervening main revisions fails on that unused forced entry, rebuild from the corrected source rather than disabling loader checks. This does not diagnose every startup failure.

The contributor reports a signed Release build with Xcode 27.1 on iPhone 16 Pro / iOS 26.6.1, installed over the existing app: character selection and area 1 entry worked, with the existing character and resources retained. Internal logs/capture reportedly show an 874×402-point window and 2622×1206-pixel texture/viewport/canvas without compatibility borders. These are dimensions, not a frame-rate measurement. The report lists 68 passing filesystem checks; the full host/graphics/rewrite suites were not rerun. The screenshot was kept locally and was not attached to the PR. SwitchToAny has not reproduced this run; duration, wider device coverage and long-term save safety are not established. At that checkpoint the release was v1.0.17; the correction is now included in v1.0.18. The older v1.0.17 tag predates #67, so neither that temporary main-only regression nor #73’s correction was part of the v1.0.17 shells.

Minimap disappearance: #64 included in v1.0.18; #61 remains separate

On 16 October, 09:17 UTC, the maintainer reported adopting PR #64 into internal main as 1f9e96a01, with public export still pending. PR #64 is closed and unmerged, not an official v1.0.17 fix. At the 09:57 UTC check, public main remained 1784563, the internal commit was not retrievable through the public API, and v1.0.17 remained the latest release. The proposal addresses a minimap that remains enabled but moves off-screen after controller/touch switching or layout rebuilds. Draft PR #61 addresses a different path: a disabled visibility flag after NPC Act travel. This reported adoption does not replace #61 or establish that issue #49 is resolved.

The PR #64 contributor reports that final head cd2200d, custom v1.0.17 build 1021, kept the minimap visible through eight input-mode switches and one background return on iPhone 15 Pro Max / iOS 27.0.1. An iPad Air 5 check used an earlier revision, not the final head. NPC Act travel, waypoints and long play were not verified; screenshots were not attached to the PR. Treat this as a scoped community report and a source to follow, not an installation recommendation or a SwitchToAny test.

17 October, 01:04 UTC: the maintainer prioritizes the NPC Act I → II / II → III path and asks that #61 remain a draft until device before/after screenshots and a Pause → Share diagnostic log are attached. This is a validation request, not a released fix; the public package at that 01:04 checkpoint was v1.0.17. v1.0.18 lists #64, not this separate #61 path.

LiveContainer Guest load failure: correction included in v1.0.18

PR #76, opened 17 October, 10:49 UTC, proposes reserved code-signature space in Guest.framework/Guest for LiveContainer’s JIT-less signer. The reported error says __LINKEDIT extends beyond the end of the file; this specific load failure is separate from the later character-naming crash below. The PR closed without a GitHub merge; the exported correction is now included in v1.0.18, while the older v1.0.17 package stays unchanged.

The contributor reports an iPhone 15 Pro / iOS 27.0 boot with a post-processed v1.0.14 package, plus a Linux signing harness and byte-comparison checks for head a054135. This is not a device run of a newly built PR package, nor a gameplay/save result. Apple codesign/Xcode, Sideloadly and AltStore were not tested by the contributor. The maintainer’s 10:49 reply requires their own Xcode/codesign validation before a merge decision. Keep the exact error and package/signing details when comparing this report; that initial contributor report was not a released fix or a reason to modify signing settings or discard resources/saves. SwitchToAny has not reproduced it.

11:05 UTC follow-up: the maintainer reports macOS checks using their own r44 output: deterministic output, unchanged code/writable data, and successful Apple codesign replacement and strict verification. Adoption was undecided at this 11:05 checkpoint. That reply supplied no newly built package/device retest or release; the later adoption and signer checks follow below.

11:19 UTC adoption: the maintainer closed PR #76 without a GitHub merge after exporting the correction to public main 3af961d. It affects shell/user-side packaging through d2rm_pack.py; the published v1.0.17 tag and shells are unchanged. At 11:26 UTC, the maintainer also reports macOS checks of the ldid component used by AltSign: old/new Guest, ad-hoc/test-certificate signing, valid file bounds and no page-hash mismatches. This is signer-component verification, not an end-to-end AltStore install or a new LiveContainer package/device retest. At that 11:26 checkpoint, Sideloadly remains untested. Keep version-matched instructions; this source change does not certify the unchanged released package or resolve the separate naming-keyboard report.

Community LiveContainer report: keyboard crash before first play

On 17 October at 06:58 UTC, jiayx issue #16 reports repeatable exit when the system keyboard appears during new-character naming: M1 iPad Pro 11-inch (third generation), iPad13,4 / iPadOS 26.5.2 / LiveContainer 3.8.10, using a community-built v1.0.17 build 1.1, shell 3.3.94012-r44, iOS 26 IPA. The reporter says all 18 resource archives pass and the main menu loads. At this original 06:58 checkpoint: No maintainer diagnosis or confirmed fix is supplied. The proposed GPU cause and exclusion of out-of-memory are the reporter’s interpretations, not established here. This is not evidence that all M1 devices, v1.0.17 packages or LiveContainer installs fail. Resource/menu success is only an intermediate checkpoint; first-character creation and the play/save/reopen checks still matter.

08:28 UTC follow-up: the community-build maintainer proposes a diagnostic comparison using the existing v1.0.17 build 9.1 iOS 18-compatible build on the same iPad with the same LiveContainer mode/settings. Here iOS 18 is the minimum OS, not a request to downgrade iPadOS 26.5.2; the maintainer describes its traditional Metal path versus the standard iOS 26 build’s Metal 4 path. Existing Data can be retained, and saves should be independently backed up before any build change. At the 08:28 checkpoint no successful result or confirmed fix had been reported. This is an attributed test suggestion, not an installation recommendation or an instruction to uninstall or reset anything.

12:33 UTC reporter follow-up: the original reporter says switching to build 9.1’s iOS 18-compatible variant allowed normal play; the issue closed at 12:58 UTC. This follows the same M1 iPad / iPadOS 26.5.2 / LiveContainer report above; it does not describe an OS downgrade. Session duration, exact gameplay coverage, save/reopen results and independent reproduction are absent. It is one user-reported result, not proof of the crash’s cause, a general LiveContainer fix or a SwitchToAny installation recommendation.

Xcode 26.2: reported Background Assets compile failure

Issue #78, opened 17 October at 16:06 UTC, reports three missing-method errors for BAAssetPackManager with Xcode 26.2 (17C52), M3 Max and macOS 15.8.1. The report does not name an exact project revision. The current source calls the named newer APIs behind runtime availability checks; that source observation is not our reproduction of the SDK failure.

The contributor proposes compatibility declarations and an older managed-download path, and reports an unsigned Release build using existing generated inputs. There is no maintainer adoption, signed installation, actual managed download or device regression. The guide retains the author’s recorded Xcode 26.6 toolchain; this report does not establish a new minimum or a universal “all Xcode 26 versions work” claim. If your error names assetPackIsAvailableLocallyWithIdentifier: or getLocalStatusOfAssetPackWithIdentifier:completionHandler:, compare the Xcode/SDK and exact source first. Do not treat it as a missing game archive or a signing problem, or apply the unaccepted patch as a verified fix.

Update check shows HTTP 530: preserve the installed game and saves

Issue #79, opened 16:29 UTC, relays build 10172332 / iPad17,1 / iPadOS 27.2 (24B5099f) logs showing three HTTP 530 update-check failures. The contributor separately reports an outside-app request at 16:28 UTC with a 1033 response body; the original app log records only 530. SwitchToAny has not probed the endpoint or reproduced the device behavior, and no exact release mapping is supplied. A status code alone does not identify the underlying server/process/network cause or establish that service has recovered.

The source makes this a background check only for builds configured with SWUpdateURL and a suitable build number; it does not block entering the game. The same-host “open in browser” suggestion is not a verified workaround for an unavailable service. Keep the exact error/build details and retry later; do not reinstall or delete saves just to address this update-check message, and do not substitute an unverified mirror.

PR #80, head 4976947440907ddea8662c12d15fe0626dee6aa1, is draft and unmerged at the 17:00 UTC cutoff. It proposes service-unavailable wording and preventing rejected responses from applying render_safe. The contributor reports 36 response-policy checks, UBSan and SDK syntax checks, with full native UI/iPad acceptance still pending. These are proposal checks, not a released client fix or restoration of the update service. Public main and v1.0.18 do not contain this draft.

Quick actions appear as empty touch slots: contributor fix awaiting merge

PR #81, opened 17 October at 17:17:58 UTC, reports that assigning global actions such as Swap Weapons or Map on iPhone retains the native binding but leaves an empty touch slot. The proposed change at f08efc2 exempts native UI actions 357, 358, 360–364 and 370 from learned/item-skill ownership checks; Town Portal 359 keeps its existing handling. Removed equipment skills and unrelated IDs remain checked. The PR is open, non-draft and unmerged at the 19:03 UTC check; main 9393b00 and v1.0.18 do not include it. Do not treat this proposal as a released fix or rebuild recommendation.

The contributor reports 17/17 production-predicate checks (8 failures before the change), host/graphics tests and an incremental signed Release build. On iPhone 17 Pro / iOS 27.0.1, an isolated save copy reached the game/HUD, Save and Exit and save commits; 33 files in the formal save directory remained hash-identical. This is a startup/save smoke report, not individual validation of every action gesture or save recovery. Three private-fixture tests were skipped, the aggregate regression command failed because LLVM objcopy/objdump were unavailable, and Mac smoke was not run. SwitchToAny has not run these checks or tested the game.

Other interaction proposals: drafts are not released fixes

Three community proposals were opened or revised at 17:40–17:42 UTC and remain draft and unmerged at 19:03:

• #82 close-button targets, head 304782948f652336fef67994c58f9f56f8f278f8, expands only the outer close-button snap reach from 90 to 160 scaled layout units, preserving ordinary-control priority, clipping and layering. These are source coordinates, not physical iPad measurements. The contributor reports 16 checks at two resolutions and UBSan; real touch ergonomics, adjacent controls and settings/modal behavior remain untested. Tracking issue #84.
• Revised #50 tooltip placement, head 6ad3590665e9203327c18215f6938c4254bb7099, keeps the spare side panels requested by the maintainer, chooses the selected item’s side and retains the native vertical target/height. It supersedes the earlier native-only proposal. Reported callback/UBSan tests do not prove the final text fits without covering slots; native iPad/wide-iPhone screenshots and interaction acceptance remain pending. Stash/vendor/cube/mercenary paths are excluded.
• #83 potion-code allowlist, head ee98a622ba638e1ca438f55508c5e2330c02e3e0, allows only hp1–hp5, mp1–mp5, rvs/rvl in the automatic sender while preserving manual pickup and display filtering. The contributor reports 70 classifier checks and UBSan. This is defensive hardening, not a reproduced root cause or confirmed fix for #9. That report remains open; a log label saying “player tapped” does not prove physical input.

None reports a full game build or post-change iPad rendering/interaction acceptance. These proposals are absent from main 9393b00 and v1.0.18; host assertions do not establish a player-ready remedy.

Foreground audio interruption: source fix; release shells pending

Issue #77, opened 17 October at 13:32 UTC, reports that foregrounding the game interrupts ChatGPT live voice/screen sharing and background music; switching away restores them, and setting game volume to zero does not help. The reporter gives only iPhone / “ios27.01”, without a model, project version, exact build or signing route. Do not assign this report to a particular v1.0.18 package.

At 13:45 UTC the maintainer attributed it to the Playback audio session lacking MixWithOthers. Public main 9393b00, exported at 14:08:47 UTC, retains Playback, adds MixWithOthers and logs the effective setting. The 14:39 UTC owner follow-up closes the issue after reporting three device smoke runs; v1.0.18 does not include this announced fix. Source builders can rebuild from the corrected main, while release-shell users must wait for the next release. Closing the issue does not update the published shells.

The smoke report does not identify the exact device/OS, session duration or each voice/screen-sharing app tested, and SwitchToAny has not reproduced it. With the source fix, background music continues alongside game audio; the maintainer suggests pausing music if only game sound is wanted. Muting the game is not an established workaround for an older build. Do not change system security, signing or saves to address this audio report.

Fresh Mac save: main menu and Options can be unreachable

On 16 October at 16:47 UTC, the maintainer confirmed issue #72: with no character in the save directory, Mac/controller-mode front-end automation repeatedly returns from the main menu to character creation, blocking Options/Credits. The reporter used native Mac source 17845634 on Mac16,8 / macOS 26.7.1. The maintainer confirms two workarounds: create a character first, or set the launch environment variable DM_FE_AUTO=0 to disable front-end automation. For a first session, continue from class selection with a non-hardcore test character; do not delete or overwrite existing saves. See the Mac guide caveat. The maintainer plans to queue a fix; it is not released; SwitchToAny has not reproduced either workaround. This is not a diagnosis of every menu problem.

Mac mouse delay: source change included in v1.0.18

PR #65, opened 16 October at 09:31 UTC, merged at 17:15 UTC as 098d9f5. It dispatches world clicks on button-down and updates held ground movement each 30 Hz tick, removing the programmed 300 ms initial wait and 200 ms steering interval; display pacing is unchanged. The contributor’s head ab6bcee report covers host regression tests and 34 injected input events in a native macOS 26 / Metal 4 app with audio disabled. After the 16:52 UTC request for hands-on Mac validation, the 17:15 UTC maintainer reply reports rerunning t_touch_mac (29 checks) and t_interaction_diag (18 checks), and confirms the new path is limited to live Mac mouse mode; touch/script/iOS/tvOS/controller paths remain unchanged. No detailed physical-mouse session, mouse-to-display latency measurement, combat-frequency benchmark or audio test is supplied. This is a public-source change, included in v1.0.18 but not the older v1.0.17 shells, and SwitchToAny has not run it.

Apple TV follow-up: local gameplay report; now publicly exported

On 16 October, 09:21 UTC, the maintainer reported internally adopting PR #56’s TV-specific generator and README as 3e5da1ca2, awaiting public export; the PR closed without merging, and the internal hash was not publicly retrievable at the 09:57 UTC check. Separately, the contributor’s 15 October README update at PR head 8f39e92 reports gameplay/settings and divider/A-button checks on Apple TV 4K (third generation, A15), using the earlier local port ea86e79. This is not a device regression of the final PR head or current upstream integration. Long-session stability, full controls and reliable saves remain unverified. Fixed 1600×900 rendering exited with signal 9 of unknown cause; the author restored 0.75 initial scale with dynamic scaling, not a stable fixed-900p recommendation. The Caches save risk remains. No new Apple TV package or supported player-install route was released, and SwitchToAny has not tested the 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.18 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 lists two shell ZIPs plus SHA256SUMS.txt. Source archives are separate. Read the notes before selecting a file.
• v1.0.18 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.18. The rewriter remains r44, but these fixes are in the app: an older shell does not gain them from newer source. Redo packaging step 1; resource archives already on the phone stay in place. Xcode users must update the source and rebuild. v1.0.18 was published on 17 October 2026 at 13:11:59 UTC. 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.

Independent community builds: jiayx v1.0.18

For readers comparing prebuilt app options, separate publisher jiayx released iOS build 10.1 at 14:23:50 UTC and Mac build 9.1 at 14:22:13 UTC on 17 October. Both name D2R source 120fe55; their labels distinguish iOS 18–25 / 26+ and macOS 15–25 / 26+ variants. Both release descriptions explicitly say no physical-device test. These are independent community packages, not the upstream shell release or a SwitchToAny-tested installation route.

Their source predates 9393b00’s audio fix, so the later upload time does not mean they contain it. The earlier build-9.1 LiveContainer user result above cannot validate these new builds. We checked notes and asset metadata only, not package contents, signing, gameplay or save/reopen. Use only game files you are entitled to supply; this pointer does not endorse third-party resource bundles or expand the device/signing limits above.

18 October, 06:25 UTC: check the unresolved Mac resource report before choosing build 9.1. Issue #17 reports v1.0.18 build 9.1 / macOS 26 rejecting a folder with 18 data files because build_manifest.psv and .build.config are missing. The reporter says copying older-build metadata allowed startup, but there is no publisher confirmation or replacement release. We have not inspected the packages or verified that cross-version workaround, and do not recommend mixing metadata. Check the publisher’s issue and matching resource requirements first; exact Mac hardware, duration and save/reopen results are absent.

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

Historical v1.0.16 changes, inherited by v1.0.17: Apple TV preview and save-related changes

The withdrawn v1.0.16 was published on 15 October at 11:00:23 UTC with tag commit afad65c895386a96dfb863f2317e41d61222a5a9. The earlier source findings below are now included in that release; the v1.0.17 hotfix notice above takes priority. Upstream main 44a6770, followed by README revision 15b837c, contains changes not included in the v1.0.15 shells. Use the exact tag and matching shell for your chosen release; do not combine the earlier intermediate revision with a shell.

• Apple TV is a community developer preview. The separate DmTV target was contributed by yinqingyan under MIT with explicit permission. The maintainer’s adoption report attributes character selection to the author’s Apple TV 4K (third generation, A15), with the ASTC Legacy Device Pack and a recognized 8BitDo Ultimate controller. Creating a character, entering gameplay, full controls and saves were not established by this pinned checkpoint; the maintainers had no Apple TV device test. The later community report is separately dated above. This is not a released, supported player-install route.
• Apple TV save warning: the pinned tvOS documentation puts saves in Caches, which tvOS may purge under storage pressure. There is no durable save solution or iCloud sync yet. An extended gamepad is required; the Siri Remote is insufficient. The simulator cannot run this renderer.
• Rift Guardian waves: PR #45 was closed after its fix was adopted into main. Delayed waves wait outside the run’s Rift maps and resume on return. Issue #44 was closed as fixed in v1.0.16. This is no longer only a draft proposal, but it is not a v1.0.15 fix or our device verification.
• iCloud shared-stash conflicts: main adds in-game return of pending local items and gold, plus Chronicle merging. The implementation returns items to inventory while the stash is open; capacity limits can leave more pending. It retains the conflict packs and uses save-commit checks. The v1.0.16 release warning now confirms a defect in this return path; see the warning above. Source inspection does not establish loss-free recovery on devices. Keep independent save backups; v1.0.17 reports fixing repeated returns without changing already lost or duplicated items. This does not add iCloud to free-account packages or self-built Mac apps.

The same main commit reports Mac resource-folder selection and display-paced frame timing changes. None of these source changes expands the tested-device list. SwitchToAny has not built or run the game or tested save recovery.

v1.0.16 source findings: Rift balance, 3D quality and display recovery

The 09:12 UTC source commit afad65c is also not included in the v1.0.15 shells. It changes player-facing behavior as well as performance-related code:

• Rift defaults change. In Rift setup, base monster-density configuration moves from ×3 to ×1.5 of the original area value, and the tiered elite-pack multipliers move from ×2–4 to ×1–2. Default base progress falls from 250 to 125. These are default Rift-mode rules, not a graphics-option toggle or a halving of monsters throughout ordinary adventuring. Tier-specific adjustments, caps and rounding still apply; configured multipliers do not establish actual encounters. The author intends to reduce load while retaining run length, but neither unchanged duration nor 60 fps is established by this source check.
• A separate 3D-quality choice. The new Custom > 3D Quality option defaults to Smoothness first: sustained frame drops can lower 3D resolution, with recovery when stable. Quality first keeps the configured resolution instead. The controller changes the 3D image, not UI/text resolution. This trades detail for rendering load; it is not a guaranteed frame-rate improvement ; it is inherited by v1.0.17.
• Volume-key/display stalls. The renderer falls back to presenting frames itself when the display callback has stopped for over 0.5 seconds while active, and returns when callbacks resume. The author connects this to the apparent freeze after volume-button presses; this does not diagnose every black screen or crash.
• The commit also reports audio-gap and UI fixes. Its extra minimap/level-transition logging is for investigating #47 and #49, not evidence that those issues are fixed.

These are source findings and attributed reports, not SwitchToAny device tests. Current download and installation instructions are pinned to v1.0.18.

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. At this v1.0.14 checkpoint, devices with 4 GB RAM remained unsupported. See the separately dated mini 6 report; the older memory reduction was 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.

17 October author update: at 08:09 UTC, Joe reported an initial broader packaging prototype and listed several games in its tests; automatic full-screen adaptation was still in progress. A one-command iOS package in ten minutes, stable play, a 30 fps floor with higher frame rates where energy use permits, and low energy use are the author’s claims and goals, not measured compatibility guarantees. His 10:33 images show a Silksong title menu and an Animal Crossing scene, without device/OS, measured FPS, duration or save/reopen evidence. At 10:39 UTC he still said the development tools were awaiting publication. Windows preparation and a Mac version are statements about his own planned tool, not validation of a Windows-only nxnative route. No new public tool or usable installation route was established at this check. Keep following the released, version-specific instructions above; these posts do not turn every named game into verified support.

17 October, 15:34 UTC scope clarification: Joe says Switch 2 / NS2 is not supported in response to a question about Switch 2 versions in his general-tool discussion. This limits his current proposed tool; it is not a statement about every porting tool or nxnative, a new public release, or proof that every original-Switch game works.

17 October, 03:19–03:28 UTC: D2R Mobile author Joe recommended the independent seedds/nxnative project to readers waiting for broader porting, then pointed them there again. This is a project recommendation, not a D2R general-converter release or a compatibility guarantee. When asked about Windows preparation at 04:34 UTC, he said he was unsure about nxnative. Its current instructions still require a Mac with Xcode and the listed tools, your own matching game inputs and keys, then signing/sideloading. A Windows-only nxnative preparation route is not established. Read the version-specific game reports below before choosing it.

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. That revision still targeted the game’s native 30 fps.

The 15 October, 04:56 UTC timing patch supersedes that limitation for newly rewritten Engage 2.0.0 code: it sets Unity’s vertical-sync count to 1 so the existing game presentation mode uses the game’s own 60 fps timing. This is a game-code correction, not a recommendation to force DM_PRESENT_INTERVAL=display on older builds. The author reports a Mac save-list timing comparison against the original 30 fps and a 370-second prologue → battle → combat → dialogue run without a crash. This does not establish corrected 60 fps gameplay on every iPhone.

Two further source commits stub unsupported shop/system applets to avoid a crash and index read-only RomFS directories. The author reports Mac first-frame time improving from 21.5 to 5.7 seconds; these are source changes and author measurements, not our benchmarks. The shop stubs do not enable eShop access, and these commits do not report fixing the background-return audio problem.

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.

nxnative: device requirements, eight iPhone titles and separate Mac reports

18 October, 05:31:54 UTC: Odyssey joins the author’s iPhone-playable list. a0d9dfd and its README add Super Mario Odyssey, base +1.4.1, bringing that list to eight. The author reports 60 fps on an iPhone, a roughly 6 GB IPA and the fog fix in the latest build; the gallery image was captured on Mac. This updates Odyssey’s earlier Mac-only status, not a sustained-performance promise. Exact iPhone/OS, session duration, save/reopen and full-game coverage are absent; no separate iPad test is supplied. Three thunder-effect geometry shaders still do not translate.

At 05:14:31 UTC, ea2e37e completes the previously pending BOTW, 3D World and Dread shader tables; all eight existing games’ lists now name their current chains. ca7216c corrects Odyssey’s zero-size fog splats, with a Mac check; the later iPhone report says that fix is included. These source and author checks are not a new all-game phone regression. Odyssey starts with the 3D touch layout. The hardware requirements below, Mac preparation, signing and independent-save precautions remain. Hades is still untested on iPhone and cannot be packed by the NSP script; Releases remains empty. No SwitchToAny game test is claimed.

18 October, 02:29 UTC: check the tighter nxnative device requirement before building. cb30943 removes the older-GPU BC-texture decompression paths and DM_TEST_NO_BC. The updated README requires iOS/iPadOS 26+ on an A17 Pro-or-later iPhone (iPhone 15 Pro or newer), or an M1-or-later iPad. This is the project’s declared requirement, not proof that every eligible device was tested. The earlier iPhone 14 Pro/A16 workaround below is historical and no longer a supported path in current main. Do not apply D2R’s Legacy Device Pack instructions to nxnative; preserve independent saves before changing builds.

02:29:06 UTC: Hades, base +1.0.38233, has an author-reported Mac result. 2bbf0d5 adds a Vulkan-on-Metal layer and reports the title, intro and Tartarus gameplay at 60 fps on Mac, with clean Metal validation. No exact Mac model/OS, session duration, sustained-performance benchmark, save/reopen or full-game coverage is supplied. The development notes keep EOS online services offline and say the NSP script cannot pack Hades yet because it does not translate Vulkan shaders. Separate manual shader/build instructions are not iPhone/iPad acceptance or a ready-to-install release.

Historical 02:36:32 UTC checkpoint (superseded for Odyssey by the 05:31 report above): README 427f51d now explicitly says both Odyssey and Hades play on Mac; their iPhone builds remain untested. This resolves the older Odyssey README discrepancy below without changing the seven-title iPhone report. 8bd6ecc updates matching tables after rebuilding the Odyssey, Link’s Awakening, Engage, 13 Sentinels and Wonder shader libraries; BOTW, 3D World and Dread are still rebuilding at this checkpoint. The 02:29 README change also removes 3D World’s old magenta-squares entry, citing an iPhone fix confirmation; exact handset, OS and duration are not supplied. Engage’s background-return audio issue remains. No new release, all-device guarantee or SwitchToAny game test is established.

18 October, 00:22:56 UTC: Odyssey now has a Mac playability report. f1cc6be reports Super Mario Odyssey, base +1.4.1, playable on Mac after H.264 tutorial-video decoding, controller-history/stick input and HUD-mask changes. A Metal compilation flag corrects stale 32×32 ground blocks in Cap Kingdom; the reported comparison covers four consecutive frames after recompiling 78 vertex shaders. This supersedes the earlier no-image Mac checkpoint below, not the seven-title iPhone list.

At the historical 00:22 checkpoint, the same-revision README still labels Odyssey “being ported, not playable yet”; the new claim is specifically the commit’s Mac author report, not iPhone/iPad acceptance. No exact Mac model/OS, session duration, measured FPS, save/reopen or full-game result is supplied. Development notes still list three untranslated geometry shaders for a thunder effect. All eight shader-chain versions changed; the commit says matching Mac libraries/tables are still being rebuilt. Smoke checks of the seven earlier titles on Mac report only their known diagnostic errors. There is no new release or SwitchToAny game test, and no demonstrated turnkey build or phone performance result.

Cuphead-related tooling, not a playable-game announcement: d8f59ab at 00:59:19 UTC and 90d2992 at 00:59:56 UTC adapt jump-table and older Unity shader/serialization handling from PRs #1/#2. The maintainer says Cuphead itself could not be rechecked without the game; verification instead compares existing-game outputs and a synthetic jump-table case. Both PRs were closed after adapted source changes, not merged unchanged. No Cuphead boot, rendered play or iPhone support is established.

17 October, 18:25:10 UTC: d0c2679 and the same-revision README move Link’s Awakening, base +1.1.0, into the iPhone-tested/playable table after the physics, outdoor-blur and sunlight fixes. That brings the author’s list to seven, adding this game to the six in the dated table below. This supersedes the earlier “iPhone testing” status, but supplies no exact iPhone/OS, session duration, save/reopen or full-play result. It is no separate iPad or SwitchToAny test. Mac preparation and iOS/iPadOS 26+ still apply; Releases remains empty.

The preceding 17:44:42 UTC e81d66f change initializes unwritten vertex-output components to the hardware defaults to address dim outdoor light and missing sun shadows. At 18:25, the remaining BOTW/3D World/Dread tables are reported rebuilt to match the new shader chain. Two not-yet-encountered pixel shaders and SR_Y_DIRECTION remain open; the playable label is not complete graphics coverage. The app’s displayed version now follows the packed game’s update/base version, so record the nxnative commit separately.

Historical 17 October, 18:25 checkpoint: Super Mario Odyssey, base +1.4.1, was not playable yet. The same 18:25 commit reports reaching its frame loop on Mac, beyond frame 8,700 over 150 seconds, while shader libraries were still building and nothing was drawn. This is startup bring-up, not rendered gameplay, an iPhone result or a 58 fps performance benchmark.

Historical A16/BOTW investigation: current main has removed this path

add5166 at 18:45:47 UTC changes texture attachment, pipeline prediction and sampling-view checks to use the original NVN format, avoiding the invalid R8Unorm → RGBA16Uint view on no-BC GPUs. The maintainer reports reproducing and clearing that assertion on Mac with DM_TEST_NO_BC=1, with other-game smoke checks unchanged. There is no new post-fix iPhone run, save/reopen test or released package. The BC4 content is still not rendered; the fix avoids the abort rather than completing that graphics path.

In the 18:46:10 UTC owner reply, #4 stays open for memory pressure. The earlier 13:12:28 UTC community follow-up, using a local workaround on iPhone 14 Pro/A16, reports system termination after about 200–220 seconds even with a roughly 4.1 GB limit; handheld mode did not materially help. That older run is not a retest of add5166. At that 17 October checkpoint, BC-to-ASTC conversion was future work, and nxnative does not include D2R’s offline Legacy Device Pack tool. Do not transfer D2R pack instructions or treat an increased-memory entitlement as a verified stable-play solution.

Dated baseline: six iPhone-tested titles reported on 16 October

16 October, 14:18 UTC: the updated README now describes all six listed games as tested and playable on an iPhone. This supersedes the earlier no-IPA statements retained below as dated history. It is an author report, not a SwitchToAny device test, an all-device guarantee or a full-playthrough result. The README requires iOS / iPadOS 26 or later; its iPhone claim does not establish a separate iPad test. GitHub Releases remains empty at review.

The listed inputs are the base game plus these updates:

Game	Update
Super Mario Bros. Wonder	1.2.1
Fire Emblem Engage	2.0.0
Metroid Dread	2.1.0
13 Sentinels: Aegis Rim	1.10
Super Mario 3D World + Bowser’s Fury	1.2.2
The Legend of Zelda: Breath of the Wild	1.9.0

The author lists optional supplied DLC for Engage and Breath of the Wild, and 60 fps upgrades for those two games. The report does not specify the tested iPhone model, exact OS, per-game session duration, save/reopen checks or full-game coverage; it is not a sustained-performance benchmark. The BOTW frame-limit patch still falls back to 30 fps when frames take too long. At that 14:18 checkpoint: Engage background/resume audio loss and 3D World World 1-1 magenta squares were listed as known issues. Neither was reported fixed at that revision; see the later graphics-fix report below.

The 14:06 touch-control change adds a remembered 2D / 3D switch. 3D includes the right stick, D-pad and L3/R3, and is the initial layout for 3D World and Breath of the Wild; the other games start in 2D. A connected controller hides the touch controls. These are documented controls, not our interaction tests.

Preparation still needs a Mac with Xcode and the required tools, your own lawfully prepared game inputs and keys, and a separate signing/sideloading step. The author’s build estimates are 30–60 minutes for a first build, about 10 minutes later, and free disk space of roughly twice the NSP inputs’ size plus 10 GB. These are planning estimates, not measured guarantees or a phone-only preparation route. Keep the save-migration precautions below.

17 October, 12:51 UTC A16/BOTW report: open issue #4 reports a texture-view assertion shortly after launch on iPhone 14 Pro / A16 / iOS 27.0, using 9579030 and BOTW 1.9.0. The reporter attributes it to the no-BC-texture path and also reproduces it with a forced no-BC path on Mac. Their local workaround reaches the field in the Mac diagnostic path but discards the GPU-generated BC4 texture’s contents; it is not a complete fix or an installation instruction. The reported approximately 3.9 GB versus 2.8 GB memory figures do not establish an iPhone memory budget, and the reporter warns of additional pressure. At that 12:51 checkpoint there is no merged fix, duration/save validation or SwitchToAny reproduction; see the later source fix and unresolved memory limit above. The older six-title author report must not be read as verification for every iPhone model.

nxnative 16:41 follow-up: graphics-fix report and language default

In commit 20cba12 on 16 October at 16:41 UTC, the author reports fixing iPhone 3D World World 1-1 magenta blocks by ending the affected render pass, copying its attachment, and sampling that snapshot for selected draws. The README at that same revision still lists the magenta squares. At that 16 October checkpoint, treat this as an author-reported source fix with inconsistent documentation, not a SwitchToAny-verified fix or a new release. The commit names A20 Pro and M4 Pro chips in the diagnosis but gives no exact handset model, OS build or run duration for the fix. Engage’s background-return audio issue remains listed; the six-game report and its other limits above are unchanged.

Game language now defaults to English. For Simplified Chinese, add DM_LANG=zh-Hans on its own line in Documents/env.txt. This setting belongs to nxnative, not the D2R Mobile Options → Custom language control. GitHub Releases remains empty.

nxnative 17 October: history before the 18:25 iPhone-playable report

17 October, 00:28 UTC: the new README separately adds The Legend of Zelda: Link’s Awakening, base game plus update 1.1.0, as running on Mac and not yet tested on an iPhone. The existing six iPhone-tested titles above are unchanged. Development notes describe initial startup and new-file name entry; graphics notes cover the house, beach and menus. At that 00:28 checkpoint, one shadow-map pipeline failed to build and two pixel shaders failed translation although the recorded runs had not loaded them; see the 07:34 follow-up below. No Mac model, OS, session duration, title-specific save/reload verification or full-game coverage is documented. This is an author report, not a SwitchToAny runtime test or compatibility guarantee.

The same update reports a BOTW HUD button-prompt shadow-box fix for Mac and iPhone, targeting one named shader; its documented comparison uses a Mac shrine route at frame 7000. At that 00:28 checkpoint: Other screen-specific shader variants may still need work. The 03:34 follow-up below expands this handling. It is not a general graphics fix or a device-wide performance result. The 00:28 README’s known-issues list still includes Engage background-return audio loss and 3D World magenta squares. GitHub Releases remains empty; these source reports do not provide a released package.

03:34 UTC follow-up: source commit 65fa9ca reports a fix for the cream cloud rectangles left behind BOTW prompts after that first shadow correction. It expands alpha-from-red handling to all 26 pixel-shader variants of the layout library, restricted to render targets. The documented comparison is on Mac during prompt fade-in; the steady bar, location title and pause/controls screen stayed unchanged. The symptom was reported on iPhone too, but no new iPhone fix-validation session, exact device/OS or duration is documented. This is an author-reported source correction, not a SwitchToAny test, general graphics guarantee or released package. The README still separates six iPhone-tested titles from Mac-only Link’s Awakening.

07:34 UTC follow-up: 9579030 reports restoring Link’s Awakening music/effects (previously only movies had sound), correcting the flickering white doorway-lighting tiles, and fixing the shadow/depth pre-pass that hid the palm tree and flowers. These are author-reported source fixes, not our runtime tests. The same-commit README still says Mac running / iPhone not yet tested, while graphics notes label the doorway correction “Mac and iPhone.” No iPhone model, OS or validation session reconciles that discrepancy. Do not infer newly verified iPhone support, full-game/save reliability or a released package; the earlier shadow/depth pre-pass failure is reported fixed, but two pixel shaders still fail translation (not loaded in recorded runs) and SR_Y_DIRECTION remains open.

13:04:33 UTC follow-up, reconciled in this review: 280ead9 and its README now describe Link’s Awakening base +1.1.0 as in testing on an iPhone, superseding the older no-iPhone-test wording. The author reports stencil-copy and outdoor-shader corrections, but provides no exact iPhone/OS, session duration, save/reopen or full-play result. This is not a completed iPhone compatibility test or a fix for the separate A16/BOTW issue. No GitHub release is available.

The same revision changes the script’s handling of unsupported games: it writes a survey, guesses a provisional profile and tries to produce an IPA; --survey-only stops at the survey. The README explicitly warns that the IPA may not start. Producing a file does not establish launch or playability, and those games remain unsupported. This is nxnative’s separate experiment, not a release of Joe’s announced general tool.

15:27 and 16:02 UTC source follow-ups: d1d68e8 reports fixing a physics-worker crash when conversations/cutscenes switch Link’s Awakening to 30 fps. Its reported post-fix checks are Mac stress runs with 138–257 transitions and house entry/exit. f900279 then follows the game’s runtime depth mode to correct full-screen outdoor blur; the author checked Mabe Village on Mac and compared Wonder’s title. These checks do not validate the latest fixes on iPhone, sustained performance or save/reopen. At that 16:02 checkpoint, the README still says iPhone testing in progress, with no release. Mac shader libraries were rebuilt for Link’s Awakening, Engage, 13 Sentinels and Wonder; other profiles were described as following. Removed “Mac” gallery captions do not turn those source-described Mac captures into iPhone evidence. The separate A16/BOTW issue #4 remains open.

Related project renamed nxnative: check saves before changing builds

The same repository is now seedds/nxnative, formerly smbw-mobile: GitHub redirects the old name and identifies both as repository 1416502082. The rename does not establish universal compatibility. Its 16 October, 14:18 UTC README lists six profiles: Wonder, Engage, Metroid Dread, 13 Sentinels, Super Mario 3D World + Bowser’s Fury and Breath of the Wild; at that checkpoint, other games produced a survey, not an IPA. The later Link’s Awakening reports, including the 17 October 18:25 iPhone-playable update, are separate above. No GitHub release was published at this check.

Save migration warning for nxnative, not D2R Mobile: the later 5c592cd app-identity change derives the app name from the base game’s control data and changes the default bundle ID to org.nxnative.<base game title ID>. A changed ID installs as a separate app, so existing Documents/save data needs to be copied over once. This supersedes the rename commit’s earlier statement that Mario’s old ID would stay. Signing tools can also replace IDs or create a new data folder. Preserve a backup and the old app/data until you have checked the new app’s saves; copying is not a verified recovery guarantee.

The newer source also packs supplied Engage Expansion Pass DLC inputs; the author verified mounting and ownership detection on Mac, not DLC gameplay on iPhone. A directory-listing optimization reports a Mac first frame of 1.8 seconds. These commits do not report resolving the iPhone background-audio issue or establish iPhone battle/save testing. Use only your own required game inputs; the project does not supply game content.

Metroid Dread and 13 Sentinels: earlier Mac reports

The 15 October source update adds Metroid Dread 2.1.0. The author reports a new game reaching the first area of ZDR on Mac, with gameplay at 60 fps and cutscenes at 30 fps, including movies and music. The version-specific profile targets the base game plus update 2.1.0; this does not establish base-game-only compatibility.

At that 15 October checkpoint, this was early source-level bring-up, not a published release or full-game stability result. An unsigned IPA was built, but no iPhone/iPad device run was reported for Dread at that revision. The later iPhone report supersedes that device-status wording. SwitchToAny has not built or run it, and save/reopen behavior and end-to-end playthrough remain unverified here. The D2R Mobile player guide and its iCloud warning are unchanged.

The 15 October, 15:41 UTC source update adds 13 Sentinels: Aegis Rim 1.10. Its pinned README reports a Mac new game reaching the first battle at 60 fps with movies and sound. That 15 October README reported no IPA test. This author-reported early Mac bring-up is historical; see the later iPhone report. It does not establish complete-game compatibility or a formal release.

3D World + Bowser’s Fury: earlier Mac and diagnostic reports

The 16 October, 05:04 UTC source update adds Super Mario 3D World + Bowser’s Fury, base game plus update 1.2.2. The author reports World 1-1 on Mac at 60 fps with sound, including a five-minute level session without a crash or rising memory; Bowser’s Fury reaches Lake Lapcat. The 05:04 README reported no IPA test. These early Mac observations establish neither iPhone play, full-game compatibility nor save/reopen reliability. No formal release or SwitchToAny game test is implied.

16 October, 11:45 UTC diagnostic note: a later source comment describes iPhone-only magenta particles in World 1-1; the commit adds logging for comparison with Mac. The README at that revision still says Mac-only/no IPA tested. No device model, OS, session duration or confirmed fix is supplied. This diagnostic report alone does not establish iPhone/IPA compatibility or performance. The 14:18 iPhone report supersedes the older README wording and lists the magenta artifact at that checkpoint; the 16:41 follow-up above records the later fix claim and documentation discrepancy.

Breath of the Wild: earlier Mac shrine report

The 16 October, 08:07 UTC profile addition targets The Legend of Zelda: Breath of the Wild, base game plus update 1.9.0. The 10:59 UTC update reports 60 fps in the Shrine of Resurrection on Mac at docked 1600×900 and handheld 1280×720, improving the earlier roughly 48 fps docked report. The author reports new-game entry with sound and lighting; the frame-interval patch can fall back to 30 fps when a frame takes too long.

The 10:59 README reported no IPA test; the later iPhone report supersedes that status. The pinned README does not specify the Mac model, OS or session duration. This shrine-only author report does not establish open-world/full-game compatibility, iPhone/iPad play or save/reopen reliability. The profile contains only the merged 1.9.0 build IDs, so base-game-only compatibility is unestablished. No formal release or SwitchToAny game test is implied.

Separate project: SwitchWaker brings GameCube Wind Waker to Switch

SwitchWaker compiles the decompiled GameCube game with the Aurora renderer into a native port. It is independent of D2R Mobile, not a Nintendo-official release and not a general emulator. Its direction is GameCube → Switch, unlike the Switch → Apple/Android work above.

The project’s v0.4.2 release, published on 17 October 2026 at 15:04:49 UTC, provides separate USA and Europe Switch ZIPs with SHA-256 files. Follow the same-version installation guide and runtime-assets documentation: you need an Atmosphère/homebrew-ready Switch, homebrew title mode, and your own lawfully prepared, uncompressed GameCube ISO matching the package: USA GZLE01 revision 0 or Europe GZLP01 revision 0. The packages do not supply the game disc. Current release packages supersede the README’s older “no release binaries” description; this is not a requirement to compile everything yourself. Use the project release page rather than a third-party game bundle.

17 October, 10:52 UTC source update: main d3a19f4 merges a sea-chart zoom correction. The contributor’s 10:55 reply says each sector now selects its own island, including “Full sea chart,” and explicitly places the fix in the next release. At this 10:55 checkpoint, the current v0.4.1 packages are unchanged; this source/contributor report predates the v0.4.2 release below and is not a SwitchToAny device test.

17 October, 14:49 UTC source update: main 084291f merges 4451f9b’s Switch depth-copy correction. The contributor reports distant scenery softening on USA/handheld at Outset at noon, with 59.9 presents/s before and after. That single-scene presentation count is not a sustained gameplay benchmark. The 14:49 reply says it will ship in the next release; at this 14:49 checkpoint v0.4.1 is unchanged, with no site device test or new full-play/save validation. The later release below supersedes the pending-package status.

15:04:49 UTC release: v0.4.2, tagged at 084291f, now includes both the sea-chart and depth-of-field corrections, plus a rare crash fix affecting players who enabled the optional network debug server. The release says 0.4.x updates keep the existing disc, saves, settings and HOME icon; that is upstream guidance, not our save-migration test. Keep an independent backup and follow the same-version installation page. USA and Europe packages share the same install path, so only one region belongs on an SD card. No package was downloaded or run here.

The authors’ manual coverage is limited, mainly the opening island and selected areas; it does not establish a complete playthrough. v0.4.2 still lists missing disc videos, incomplete “Instant text” behavior in some cutscenes, and docked 60 fps falling to 30 in heavy scenes. A selected 60 fps mode is not sustained 60 fps evidence. SwitchToAny has reviewed the sources, not downloaded or run the packages or tested a device. This entry is a project/source pointer, not an installation tutorial or compatibility guarantee.

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.