Game code is rewritten during the build
S2Arm describes a static native-porting approach: it rewrites ARM64 game code during the build, then executes that code on the target processor. System services, memory behavior and graphics still need adaptation to the host platform.
This helps explain the project’s 64-bit AArch64 requirement and why a completed rewrite does not prove playability. After code starts, service behavior, graphics, input and game logic still need verification.
Graphics calls are mapped to Metal
A native host and Metal graphics backend provide target-platform capabilities. Graphics resources and shader processing are part of preparation, so different games, shader sets and cache states lead to different build times.
The v0.1.0 release notes state that the release uses the direct path. Producing a graphics library, presenting frames and rendering the correct image are separate milestones. A successful build cannot replace a visual check.
One app holds multiple games
Current S2Arm puts imported games into a shared app library. Games are prepared in the Mac or Windows launcher, then selected inside the same app on the target device rather than installed as a separate app for every title.
The launcher, game package and original game content still have distinct versions. A launcher update does not replace the runtime already built into a game package. Rebuild when the release notes require it before testing a fix.
Native describes the approach, not a compatibility verdict
Native execution does not eliminate compatibility problems. Missing system interfaces, memory pressure, shader behavior, game-specific constraints and version differences can still cause build failures, crashes or graphics errors.
This site separates upstream run records, issue records, build information and explicit unsupported cases. These are evidence categories, not guarantees from independent device tests by this site. Read the source and conditions on a game’s detail page to judge relevance to your setup.