# Test records

[← Install](install.md) · [中文](test-records.zh-CN.md)

What has been tested, on which device and version, and what is still open. Moved here from the install guide on 2026-10-26; the install guide now only covers installing.

## Audio fix

Streamed music and dialogue lookup for `content://Sound/...` paths has been fixed. Opening dialogue and music were verified locally on version 1.0.0; other versions and scenes still need validation. The renderer also runs all known audio effect types and starts output after 20 ms of queued audio (2026-10-18). Rebuild your app with the original game inputs to apply the fix. See [audio troubleshooting and validation](audio-troubleshooting.md) for details.

## Local testing

Tested on **MacBook Air M4 and Mac mini M4**. Local testing has collected **8,582 shaders**, with performance at approximately **90 FPS after shader warm-up, reaching 120 FPS in menus**.

Those are earlier local observations, not a stable frame-rate promise for every version or scene. Version 1.4.3 measurements and compilation stalls are recorded separately in [the test notes](v1.4.3-port.md).

Shaders are automatically collected, compiled and cached as you play. Returning to previously visited scenes typically brings noticeable improvements in frame rates and smoothness because cached shaders can be reused. **8,582 is the number collected so far in local testing, not the game's total shader count or a collection limit**; the cache continues to grow as you explore.

**Shader prewarming on the first launch:** Building the app prepares shaders from your selected game data and includes them in the app: every shader in the game data for its default bind state, plus every variant named in the [shared shader list](shader-list.md). Even with an empty user cache, the first launch imports these shaders. The title appears once all of them and every compatible entry of the pipeline manifest are warmed and the pipelines are in the pipeline archive (the start screen shows the progress): after an install or a larger shared list that takes a while once (Tears of the Kingdom 1.4.3 on an M-series Mac about 60–80 seconds since the pipelines are built on several threads, October 26; before, about 4 minutes; Breath of the Wild 1.6.0 about 50 seconds before that change), later starts about 12 seconds, so play starts with every listed shader and pipeline ready. `TOTK_WARM_BEFORE_TITLE=0` brings back the old order: only what the title screen uses before the first frame, the rest behind the title, and the first trip into the world waits for it (on the Mac until it is done, on an iPhone or iPad up to 15 seconds). No preliminary play session or manual cache copy is needed. The current 1.4.3 build prepares 15,266. Building the app also compiles them for your Mac's GPU. With Xcode's Metal toolchain installed they are compiled into the app (about 6 minutes on an M4 for 1.4.3) and work wherever the app goes. Without it they are compiled into macOS's Metal cache (a few minutes), and Metal finds them only while the game runs from where the app was built: if you move the app afterwards (to /Applications, for example), if macOS clears the cache (it does when the system disk fills up), or if another program was using Metal's cache while the app was built (a running game, for example; the build says so), the background warm-up compiles them again, which takes a few minutes, and new scenes can stutter until it finishes. To place the app elsewhere, build it there with `-o`; see [preparation and test details](first-launch-shaders.md). Places no player has reported yet can still need new variants, which the Mac compiles while you play (a short stutter the first time). Playing adds them to your local cache, which is reused on later launches. The game also notes every variant the shared list does not have yet in `shader-list-contribution.txt`, and every 500 of them asks once whether to send the file in a [GitHub issue](https://github.com/ly05010419/MacNativeGames/issues/new?template=shader-list.yml) ("Send" opens the form and shows the file to drag in). It never uploads anything by itself. With git, you can also merge your cache and open a pull request, as [the list's guide](shader-list.md) explains. The list holds shader and pipeline identifiers only, never game data, saves or compiled shaders; every build makes the shaders from the player's own game files.

## Tears of the Kingdom versions

The source runtime passed basic Mac checks: load, movement/jumps, menus/map, 2K, save/reload and death retry. Full-map, long-session and fair 1.0/1.1.2 performance comparisons remain pending; the earlier FPS observations are not a promise of 1.1.2 performance. Packaging validation is recorded in [the build notes](how-it-works.md#112-validation).

The 1.4.3 port has separately passed scene loading, movement/jumps, menus/map, save/reload, native 2K canvas switching and MetalFX upscaling/interpolation on an M4 Mac. The single packaged app has been tested, including save/reload, death/retry and shrine entry/exit. A three-hour earlier build and a 30-minute final-build run are recorded separately; first-use compilation stalls, long-session memory growth and audio underruns remain under investigation. See [the 1.4.3 test record](v1.4.3-port.md) for the scope and follow-ups; this is not full-game or stable-FPS certification.

The 1.2.1 port (October 19) passed the same rewrite verification (600 of 600 negative controls) and the loader, RomFS and startup probes. On an M4 Mac it loaded saves in the 1.0.0 and 1.1.2 formats and passed movement/jumps, menus/map/quick menus, manual save and reload in a new process, fall death and retry, and the three key-3 picture modes; the packaged app was also opened through its launcher. See [the 1.2.1 test record](v1.2.1-port.md); this is not full-game or long-session certification.

**CPU and GPU time in four places (1.4.3, October 28, main at `e13f030`).** Apple M4 Mac mini, 16 GB, macOS 26.5.2; a 1920×1080 window, scene at 1920×1080 (the game's dynamic resolution sometimes drops it to 1720×968 or 1536×864), default settings (frame cap 240, no frame lock, no MetalFX); Link standing still, 90 s after the automatic load, from the test save of each place. Medians of the game's own 300-frame timing lines, the first five windows after the load left out. "Submission CPU" is the replay thread's CPU per frame; "NVN submit + present" is the game side's.

| Place | Frame p50 / p95 | GPU p50 / p95 | Submission CPU | NVN submit + present | Draws per frame |
|---|---|---|---|---|---|
| Grassland (field) | 11.02 / 11.93 ms (about 91 fps) | 9.57 / 10.38 ms | 4.32 ms | 4.30 ms | about 3,670 |
| Lookout Landing, bird tower (town) | 11.92 / 12.96 ms (about 84 fps) | 9.89 / 10.69 ms | 5.22 ms | 5.19 ms | about 4,290 |
| Lasitakiwak Shrine, inside | 9.73 / 10.87 ms (about 103 fps) | 8.44 / 9.29 ms | 4.91 ms | 4.78 ms | about 11,950 |
| Room of Awakening, the opening altar | 9.48 / 10.51 ms (about 105 fps) | 7.64 / 8.55 ms | 2.05 ms | 1.95 ms | about 1,030 |

The GPU is the limit in all four (GPU 81–87 % of the frame; submission 2–5 ms runs alongside it). In the shrine, where the submission thread used to be the bottleneck (October 21: 7.0 ms per frame, frame 11.8–11.9 ms), it is now 4.9 ms and the frame 9.7 ms.

**A player's MacBook Pro with an M3 Pro (1.4.3, November 6–9, main at `9fe3fdc`).** MacBook Pro 16-inch (Mac15,7), Apple M3 Pro with an 18-core GPU, 18 GB, macOS 26.6.2, its built-in 120 Hz display; 2K + MetalFX upscaling, shadows 2x, SMAA High, sharpening 25 %, all effects on. A player's observations, not measured with the repository's timing tools, and the places in the game were not recorded.

- **Runtime update:** `update_runtime.py` took 407 s; most of it was the pipeline archive for this GPU, 27,376 pipelines for `applegpu_g15s` in 361 s, 0 failed.
- **First start after the update:** macOS's Metal compiler service used about seven CPU cores for about four minutes, and the loading screen waited until it was done. Later starts loaded normally.
- **Frame rate:** with no frame lock the game ran above 100 fps (the player then locked it at 60 or 72).
- **Long sessions:** the game's memory grows over hours: 4.2 GB four minutes after a start, 18 GB (5 GB of it compressed) after 6 h 47 min, at which point the Mac swapped and the game fell to about 1 fps. Quitting and opening the game again cleared it ([#1958](https://github.com/ly05010419/MacNativeGames/issues/1958)).

## Breath of the Wild

What works on 1.6.0 (October 20, an M4 Mac, a Great Plateau save): title, the add-on content list, loading and saving, the plateau at about 90–120 fps (the game advances by real time; held-button repeats count by real time too), the two DLC packs mounted and read, key 1 (overlays), key 2 (MetalFX frame interpolation: off → 30+30 → half the refresh rate → unlimited, every game frame interpolated on the plateau) and key 3 (MetalFX 2K on / off: MetalFX replaces the game's own upscale of the 1600x900 picture into the 1080p canvas and the window output above 1080p); a 30-minute session on the plateau at about 95 fps with memory steady (+170 MB). Since October 23 (Mac): key 2 works again (its scene detection had kept a shader key from before an October 20 change and found no frame, #177) and gives what moves with the camera, such as Link, no camera motion, so he no longer shakes at 30+30; key 3's MetalFX again replaces the game's own upscale; key 4 switches 21:9 as on 1.9.0 (1.6.0's camera writes 16:9 every frame, so the game's own write is changed); key 5 smooths edges (#178). Key 3 now cycles off → MetalFX 2K → native 2K → off as on Tears of the Kingdom 1.4.3 (native 2K renders the scene and the canvas at 2560x1440; the app starts with a 2560x1440 swapchain and bigger heaps, `TOTK_OUTPUT_RES=0` keeps the shipped 1080p only). Not yet: the DLC quests themselves (only verified as mounted and read). This is an early port: expect rough edges.

What works on 1.9.0 (October 20, an M1 Pro Mac with its built-in 120 Hz display, both DLC packs): title, loading saves, autosaves, six places from the Shrine of Resurrection to the Hyrule Castle exit at 58.4–77.5 fps standing still and 58.6–81.4 fps walking with a warm shader cache, a 25-minute run in Korok Forest with Link moving, the game advancing by real time at any frame rate (held-button counts too), the two DLC packs (the Kakariko route starts the DLC quest "EX Treasure: Garb of Winds"), key 2 (MetalFX frame interpolation: off → 30+30 → half the refresh rate → unlimited; on the Great Plateau, standing still, the game ran at 69, 30, 58 and 61 fps and the screen showed about 67, 60, 115 and 115 pictures a second) and key 3 (MetalFX replaces the game's own upscale). Since October 21, 1.9.0 also has 1.6.0's fixes above 30 fps (menus and the HUD at normal speed, six physics steps a frame, movies held at 30 fps), renders docked play at native 1080p, and has key 5 (MetalFX temporal anti-aliasing: smoother edges, about 9 fps less on the plateau at 1600x900, 67.7 to 58.6). Key 4 switches a 21:9 ultrawide view on 1.9.0 (Mac: the camera sees more at the sides and the picture fills a wider window; `TOTK_ASPECT=32:9` or `3440x1440` picks another shape and starts with it on; the HUD and menus keep their shape in the middle 16:9, the map with black bars at the sides; markers that follow objects in the world are not moved out yet). Both versions now run uncapped on a 120 Hz display too, up to 120 fps (measured on 1.9.0); before, the game's present interval held them at 60 fps there. Walking into a place for the first time stutters while new pipelines compile. Not yet: native 2K, iPhone / iPad, and a fix on main for Link's legs, which sink into the stone path after a save at one Great Plateau spot loads (the old autosave and a new save made there); the cause is known, pull request #511 (open) fixes the legs, and #239 on main cures the clear Bottomless Bog water but not the legs. See [the 1.9.0 test record](botw-v1.9.0-port.md).

## iPhone and iPad

Version 1.4.3 has been played on an **iPhone 14 (iOS 26.6.1)** and an **iPad with the A16 chip (iPadOS 26.7.1)**, both signed with a personal development team in Xcode. Versions 1.0.0, 1.1.2 and 1.2.1 have not been tested on iOS. Breath of the Wild 1.6.0 has been played on the iPhone 14 (title, loading a save, walking around; October 23): build it with `--platform ios --ios-game-data documents` and install it with `games/totk/ios/tools/install_device.py` like Tears of the Kingdom. It fills the screen and renders at 960x540 with the game's own upscale to 1280x720, as Tears of the Kingdom does on the phone. 1.9.0 builds for the iPhone the same way (960x540 too) but has not been played on one yet. On the phone both games run at up to 60 fps, the screen's rate.

- **First launch:** the app checks the game data (about 15 seconds) and imports the shaders it carries, with a progress bar. On an iPhone 14 this takes about 3 minutes before the title appears. Later launches show the title in about 8 seconds.
- **Picture:** the game runs in handheld mode, as a Switch does without its dock: 1280×720.
- **Shaders:** an iPhone or iPad cannot translate shaders while playing. A draw whose shader variant the app does not carry is skipped, so objects can be missing in places no player has reported yet. The device records what it missed in `shader-list-contribution.txt` (Files app › On My iPhone › Tears of the Kingdom); the game never asks about it during play. Once the file holds 100 new entries, the game asks once before it starts whether to contribute them; with "Contribute shaders" it uploads them by itself over HTTPS ("Contribute shaders automatically" in the Settings app turns it on or off). Once merged into the [shared shader list](shader-list.md), the next build carries them for everyone. With a Mac, `games/totk/ios/tools/fill_shaders.py` also translates them and sends them to the device right away.
- **Memory:** the game uses close to 4 GB on an iPhone 14, near what the phone can give it. In busy areas iOS can close the game after several minutes of play when the phone runs out of memory (seen twice on an iPhone 14, about 8 minutes in). Reducing the game's memory on iOS is the next piece of work.

## Automated tests

The 255 automated tests cover generated container/update fixtures, relocation formats, work-folder isolation, packaging, desktop migration, shader extraction (BNSH, agl `.sharcb` and game-module shaders), the shared shader list and the players' contribution file, first-import cache preservation, the Metal toolchain lookup, mod code-patch merging (IPS / IPS32 / pchtxt against synthetic NSO modules, with the reserved-site list read out of the C sources and the file named by its module or build id), the build's own mod install (`--install-mod-romfs`: the version folder replaced and what it held kept as a backup, a symlinked folder refused, a misspelt path stopped before anything is touched, the real `make_mod_manifest.py` run against a fake RomFS), the 2K output overlay's record of the heap table it was built on, the RomFS manifest that leaves the app's own overlay files out by itself and 27 native RomFS path cases. GitHub Actions is configured to run the source tests and the native path parser under the undefined-behavior sanitizer, without game data or keys. A complete Mac build also passed with a local XCI-derived NSP fixture and generated common ticket. An independent retail base NSP and gameplay from that input have not yet been tested.