MacNativeGames: TOTK on Mac, requirements & evidence

What is available now?

MacNativeGames is an experimental, Mac-only source project for The Legend of Zelda: Tears of the Kingdom. The author’s announcement links to ly05010419/MacNativeGames. The author reports building a Mac app and running gameplay locally. GitHub Releases was empty when checked on 18 October 2026: those local apps are not published release downloads.

The current source checkpoint is f5cc151, reviewed at 21:06 UTC on 18 October. Earlier performance records below remain pinned to their original 41e1e0c snapshot. SwitchToAny has not built or played the game. It is a project reference, with no game downloads or installation walkthrough.

iPhone and iPad are future plans. The README’s upcoming-iPhone recommendation does not establish an available iOS build, a release date or phone performance. The documented playable route at this checkpoint is Mac only.

Which Mac and game versions does it target?

The pinned README specifies Apple silicon, macOS 26 or later, and at least 16 GB of memory recommended. Metal 4 is part of the graphics requirement. The author names MacBook Air M4 and Mac mini M4 for local testing; this is not a validated matrix covering all Apple silicon Macs.

The macOS 27 startup fix is now merged. PR #11 merged at 19:49:39 UTC as dcd7d16. The README now explicitly includes macOS 27 while retaining the macOS 26+ minimum. joevans’s reported check remains M4 Pro / 48 GB / macOS 27.0.1 / game 1.0.0, to the first rendered frame only, without a macOS 26 retest, long-session or save test. The earlier failure report does not establish failure on every macOS 27 device, and a merged fix does not establish version-by-version compatibility.

Do not use the address-space fallback as a memory-requirement shortcut. Its 8 GiB minimum concerns virtual alias reservations, not physical RAM. In this main snapshot, explicit TOTK_ALIAS_GIB values below 8 can fail and larger requests can shrink. The separately cited a396e2d override-handling follow-up is not in this main snapshot; this guide does not recommend changing that override. The 19:05 checkpoint preserves the earlier unmerged state.

Three exact game-version profiles are documented:

• 1.0.0: the base game
• 1.1.2: the base plus the separate matching cumulative update
• 1.4.3: the base plus the separate matching cumulative update

A profile means the project has version-specific code and validation rules. It does not establish identical performance, full-game coverage or support for arbitrary updates. Other versions and DLC remain outside the documented support. The repository supplies no game content; the build depends on separately supplied game inputs and keys.

How does it run the game?

The technical explanation describes three layers:

1. ARM64 code: most game instructions execute directly on Apple silicon. A static, ahead-of-time rewrite replaces instructions or platform-register uses that need different handling on macOS.
2. Horizon services: a host implements the Switch operating-system services used by the game, including memory, files, input and audio.
3. NVN graphics: the game’s graphics commands are implemented through Metal 4. Maxwell shaders pass through the Ryujinx shader translator to SPIR-V, then SPIRV-Cross to Metal Shading Language, before Metal compilation and caching.

The build still prepares a version-specific shader seed and completes startup warm-up before the first frame. With merged PR #16, the build script automatically precompiles startup MSL into bundled Metal libraries when the optional Xcode Metal toolchain is present, without a separate opt-in flag. Runtime loading requires an exact local-MSL hash match. Missing toolchains, individual compilation failures or library-load failures retain the runtime-compilation fallback.

The new timing report measures shader warm-up, not whole-app startup or FPS. Contributor RVZO6 reports M4 Pro / macOS 27.0.1 / TOTK 1.4.3 / 8,290 shaders: warm-up fell from 291 to 17.8 seconds at a new location, and from 274 to 6.6 seconds after moving the app. The shader-library precompilation step reportedly took 2 minutes 22 seconds from scratch; bundled libraries added 131 MB. Only title-screen rendering was compared; gameplay beyond it was not tested. These results do not predict other machines or prove stutter-free exploration. Newly encountered binding-dependent variants can still compile during play; the separate parallel runtime warm-up PR #13 was still open at review.

What else changed in the latest source?

• Targeted graphics fixes: merged PR #3 addresses the shrine warp pad’s black texture and D16-related skill rectangles. Contributor A/B coverage was limited to the warp pad and Recall on M4 Pro / TOTK 1.4.3, with startup prewarming disabled equally and a shared local address-layout fix. It is not a performance benchmark or full-game test.
• English launcher: merged PR #12 selects English UI on non-Chinese Macs. This does not add an iPhone or iPad build.
• Command-Q: merged PR #14 uses the existing save-aware close path, with a 15-second timeout. Six standalone AppKit tests were reported, without a full game launch test; this is not a save-safety guarantee.

What does the performance evidence actually show?

The earlier 41e1e0c 1.4.3 test record reports approximately 83.9–110.2 fps, calculated from average whole-frame times across 15 valid scene points. Every point was warmed up and then sampled with a fixed camera for 30 seconds, on an Apple M4 with 16 GiB and macOS 26.5.2. The window drawable was 1280×720 and the default game canvas 1920×1080.

Those conditions matter. The numbers are short warmed-scene averages, not a sustained exploration benchmark or a fair comparison between game versions. First camera turns produced a 902.4 ms frame at one location; another test recorded a 936.2 ms compilation-related frame. An average can hide a visible pause close to a second.

The record does not verify stable 1440p gameplay. Its “native 2K” mode changes the composition canvas and UI to 2560×1440; the game’s 3D render scaling remains separate. Testing a 4K output texture also does not establish performance on a physical 4K display. The physical display used in the recorded testing was 1080p/60 Hz.

What is still unfinished?

The earlier 41e1e0c record reports scene loading, movement and jumps, menus and the map, save/reload, death/retry, and shrine entry/exit. The record covers 17 valid environments and the beginning of a new game. It does not cover a complete prologue or full playthrough.

• Long sessions: an earlier build ran for about three hours; the final recorded build ran for 30 minutes 31.68 seconds before user input stopped the monitor. These are separate runs and builds. The final-build 75-minute target was not completed.
• Memory: growth was observed during longer testing. Configuration reuse improved a specific graphics-resource pattern, but the record does not establish that all long-session growth is resolved.
• Audio: the README reports a streamed music/dialogue fix verified in the 1.0.0 opening. Other versions and scenes still need validation, and the final 1.4.3 run continued to record audio underruns.
• Graphics and timing: first-use shader stalls, some diagnostics, broader animation/physics checks and interpolation quality remain open. Online features and amiibo are unsupported.

The newer startup and UI changes do not establish that these earlier long-session, audio or gameplay limits are resolved.

How does it relate to D2R Mobile and nxnative?

The acknowledgements credit D2R Mobile for the foundational NSO rewriting, Horizon host and NVN-on-Metal work. They credit nxnative for the one-script packaging and common-ticket import approach. MacNativeGames remains its own repository, targeting TOTK on Mac; another project’s release or iPhone result does not validate this one.

The project’s MIT license covers its source under that license. Dependencies retain their own licenses, documented in the third-party notices. Neither statement grants a license to Nintendo’s game content or establishes legal clearance for obtaining, using or redistributing game files and keys. The author states that the repository contains no game content and is unaffiliated with Nintendo.

For current results from the other projects, see nxnative’s Apple-platform reports and D2R Mobile’s status. Our evidence method explains how source claims, author gameplay reports and independently tested results differ.