TEARS OF THE KINGDOM / PERFORMANCE RECORDS

Tears of the Kingdom on Mac: performance records

Compare Mac frame rates, first-visit stutter and build times. Start with the game version and scene that match how you plan to play.

Mac frame rates

DeviceVersionHow it was measuredResultRead it with
Apple M4 (MacBook Air M4 and Mac mini M4)Not stated (early builds, 17–18 Oct)Local play after shaders had warmed upAbout 90 FPS in the world, up to 120 FPS in menusThe author calls these earlier observations, not a promise for every version or scene. README, Local testing ↗
Apple M4, 16 GB, macOS 26.5.21.4.315 fixed camera points, 30 s each after warm-up; window 1280×720, canvas 1920×108083.9–110.2 FPS (from average frame time)Averages hide stutter: the first camera turn at one underground point took a 902.4 ms frame while 8 shader libraries and 6 pipelines were built. docs/v1.4.3-port.md ↗
Apple M4, 16 GB, macOS 26.5.21.4.3Same point and camera revisitedAbout 101.4 game frames per second; longest frame 63.1 msFrames over 100 ms went from 5 to 0 on the second visit: the shader cache was reused. docs/v1.4.3-port.md ↗

Comparison conditions: the author measured these on one M4 with one save, weather and time of day varying. They are not side-by-side benchmarks, and a figure for 1.4.3 does not carry over to 1.0.0, 1.1.2 or 1.2.1.

More M4 records: interpolation, memory and early builds

2-second walk, default frame rate vs interpolation “30+30”

About 79.8 FPS vs 30.0 FPS; distance walked differed by 1.26%

Apple M4, 16 GB, macOS 26.5.2 · 1.4.3. Checks that game speed does not change with frame rate on this path. Original report ↗

Long session, observed 10,821 s (3 h)

Memory footprint rose about 138 MiB each time native 2K was switched on; audio underruns 9 → 10

Apple M4, 16 GB, macOS 26.5.2 · 1.4.3. Stopped early to investigate the memory growth; long-session memory is still being worked on. Original report ↗

Title screen after the first shader compile, shipping frame controller

About 30 FPS

Apple M4, 16 GB, macOS 26.5.2 · 1.4.3 (early build). Before the frame-rate patch; not a scene frame rate. Original report ↗

For phone launch times and memory behavior, see Tears of the Kingdom on iPhone and iPad.

M1 MacBook Air: what one video shows

Andrew Tsai’s walkthrough shows version 1.4.3 on a MacBook Air labelled M1, 8 GB and 900p. The footage is useful for seeing the game run; it does not provide a sustained performance result across scenes.

Watch the M1 MacBook Air example ↗

M1 Pro/Max, M2 and M3: no records yet

The reports collected here do not provide comparable results for these chips. A frame rate for an M2 Pro or an M3 Max cannot be worked out from the M4 numbers: GPU cores, memory and the shader cache state all change the result. If you build it on one of these Macs, the method below gives a result others can compare.

How long a build takes

  1. 10 minutes with a reused work folder

    Author’s 1.2.1 record on the M4: signing about 5 min, macOS’s first check of the app 208 s, compiling 8,286 startup shaders 98 s. docs/v1.2.1-port.md ↗

  2. 39 minutes to the macOS check

    One recorded build from a 1.0.0 base and the 1.4.3 update, Metal toolchain installed, app written to /Applications. Compiling 14,704 startup shaders ahead of time took about 17½ minutes of that. The full stage log is on the build page.

  3. 28 minutes, then 8 minutes for a rebuild

    A player’s first build from an NSP with firmware fonts; running the same command again with the same work folder took 8 minutes. PR #55 notes ↗

Measure your own, so it can be compared

01

Write down the conditions first

Press 1 in the game: the top-right box shows the current interpolation and picture modes. Note whether this area is new to this Mac (shaders still compiling) or revisited.

You have chip, memory, macOS version, game version, window size, picture mode and interpolation mode noted.

02

Warm up, then watch one place for 30 seconds

Stand still or walk the same short path. The author’s method uses 30-second windows and keeps every slow frame; a single screenshot of the HUD is not a result.

You have a lowest, typical and highest reading for the same spot.

03

Note the stutters separately

Shader compilation can cause a first-visit hitch. Compare the same place again and note shader activity before assigning the cause. Report first-visit pauses apart from the steady frame rate. See why new places stutter and what keys 2 and 3 change.

First-visit hitches are listed apart from the average.