Paper Mario: The Thousand-Year Door
Runs smoothly; tested until mid chapter 1
NiXA
Your own Nintendo Switch games as apps for Android, the Mac, iPhone and iPad.
Import a game once, choose a platform, get an app: no command line.
GitHub · Coming soon!
The repository is still private. The link follows when it opens.
Platforms
AndroidNiXA's own Android runtime: Horizon on the device, NVN on Vulkan
In development
macOSThe nxnative Apple pipeline (NVN on Metal): every game nxnative lists as playable
Very stable
iPhone / iPadThe same pipeline; iOS / iPadOS 26, A17 Pro or M1 and later
Very stable
Development and testing are focused on Android at the moment. macOS, iOS and iPadOS are considered very stable, but we are not testing them ourselves right now.
What it is
A builder for the games you own. Not an emulator.
NiXA is a desktop app that turns the game files you own into a standalone app for each platform. It identifies a game from its own metadata, shows for every platform whether the game is supported there, and builds, signs and installs the app. The game's own code runs on the device's processor.
Import a game onceDrop your own game files onto the window. NiXA ships no keys and no games.
Choose a platformAndroid, the Mac, iPhone or iPad. NiXA shows where the game is supported.
Get an appBuilt, signed and installed, with a launcher in NiXA's design. No command line.
NiXA builds on nxnative and its contributors (MIT): the rewriter of the game modules, the Horizon services, NVN on Metal and the Apple pipeline come from there. On top NiXA adds the Android runtime, Nextcloud save sync, the launchers in its own design and the desktop builder.
Games on Android
Two games so far, on a Galaxy Z Fold7
Tested on the Galaxy Z Fold7. The list grows as games are brought up.
Mario Kart 8 Deluxe
In game; runs slow, lighting glitches
Note. Development and testing are focused on Android at the moment. macOS, iOS and iPadOS are considered very stable, but we are not testing them ourselves right now: test reports are welcome!
Coverage of the Android port on 2026-11-06, counted from the code. Game logos and the screenshot belong to their owners and are shown only to identify the games.
Timeline
From the first test app to a game in play
Every step of the Android port has a milestone report that records what was built and what was observed. This is the short form of the reports from November 1 to 5, 2026. The rule behind them: claim only what was observed, and stop with diagnostics instead of inventing success.
- Foundations with test code only, then the first game code
- M2
The first app builds and tests itself on the phone
A signed ARM64 Android app with a native self-test, and a platform layer that keeps the game's special registers away from the ones Android reserves.
Native self-test: 6 passed, 0 failed - M3
A tiny test program runs under the host
A self-written ARM64 test module executes on the Fold7 and returns safely. Code is never writable and executable at once.
- M4
The Switch's program format loads
A synthetic module in the Switch's executable format is rewritten, loaded, relocated and run on the phone.
- M5a
A first slice of the Switch's system
The test module uses threads, events, memory, files and time through a portable part of the Horizon services.
- M5b
Vulkan shows a triangle
The host's own Vulkan renderer presents a test triangle on the Fold7. A renderer proof, not a game renderer.
- M6a
Guest code draws its first triangle
The test module calls the Switch's graphics API (NVN), and the call ends in a Vulkan draw on the Android screen. The host itself draws nothing any more.
- M6b
A Switch shader becomes a Vulkan shader
A shader pair in the Switch GPU's machine code is translated and drawn; the picture read back from the GPU matches the reference exactly.
- M7a
Textures and samplers
Guest code draws a textured quad, verified pixel by pixel through GPU readback.
- M7b
Depth, blending and render targets
Four draws with a depth test, alpha blending and an offscreen image that is then composited to the screen.
- M8
The first real game is checked, not started
The user's own copy of Paper Mario: The Thousand-Year Door is identified and validated on the phone (boot checkpoints 1 to 3 of 12). The report calls the milestone partially complete: no game code runs yet.
- M9a
The game's modules load and link
The game's three code modules are mapped, linked and released again on the Fold7. Still no game instruction runs.
114,689 relocations applied - M9b
Thread state the Android way
The modules' thread-state accesses, rewritten for Apple devices before, get a form that never touches Android's reserved registers.
- M9b-B
The boundary between host and game
Guarded stacks and controlled transitions, proven with synthetic tests. Real game execution is deliberately not claimed yet.
- M9c
The first real game SDK code runs on the phone
The SDK's system initialization executes, makes real system calls that the host answers, and returns normally.
20 successful system calls - M9d
The Switch's memory model
One consistent model of the process's memory answers the game's queries; the next initializer runs and returns.
- M9e
The SDK initializes, then aborts
The SDK's module initializer runs. The following startup step ends in a real SDK abort, and the host stops there instead of pretending success.
- Into the game's main function, then graphics
- M9f
The abort explained
The cause was an impossible 62 GiB memory request. With the size corrected, startup and all three modules' constructors run to the end.
- M9g
The game's main function starts
The game's own entry point executes on the Fold7 and stops, controlled, at its first request to create a thread.
- M9h
Game threads
The game creates and starts its first three worker threads. The main thread stops at its first service request.
- M9i
Tracing instead of guessing
Structured tracing and a coverage matrix against the Apple host replace speculative stubs. The report calls the result diagnostic progress.
- M9j
Transfer memory
The next missing system call is implemented and succeeds on the phone; the game stops one step later.
- M9k
System services answer
The game connects to the graphics driver service and enters display initialization. It stops at the display service, which did not exist yet.
- M9l
A display for the game
The display and layer lifecycle is implemented and passes the host tests. The one device run crashed earlier, so nothing is claimed for the phone.
- M9m
The crash becomes a diagnosis
On the Fold7 the game opens the display and creates a layer. The cause of the stop is found: Nintendo's own graphics driver cannot initialize on Android.
- M9n
NiXA's own graphics layer takes over
The game's graphics calls now land in the host's NVN instead of Nintendo's driver. Its first draw runs on the phone's GPU through Vulkan, and the first frame reaches the screen (black, as expected).
First draw: 921,600 of 921,600 pixels changed - M9n
The first picture
Run 52 shows the game's first picture on the Fold7: the Nintendo logo screen. Slowly, with long loading stalls.
- From the title screen into the game, and a builder
- M9n
The title screen
After 109 runs on the phone, the game reaches “Press any button” with no stop and no crash. Still slow: about 15 pictures per second.
- M10
Past the opening, with sound and touch controls
From the title through a new file, the opening movie with its sound and the prologue, at the Switch's 30 fps with game time equal to real time. Then a controlled, named stop at a graphics feature that was not ported yet.
- M11
In game
The first area with Mario under control, the first battle, saving and loading, the home button and lock screen, music and sound through the speaker.
28.7 to 30 fps in the harbour - M12
NiXA, the desktop app
A desktop app identifies the user's own game files and builds, signs and installs a standalone Android game app, with no terminal.
- Every platform, one design
- M13
NiXA 0.2.0: Android, macOS, iOS and iPadOS
The builder also makes Mac and iPhone apps through nxnative's Apple pipeline: a Mac app started and played, an iPhone app signed and installed. 161 upstream commits were merged.
- M14
Launchers in NiXA's design, and a much faster start
Game apps get NiXA's launcher on the Mac, the iPhone and Android. On the way, the Android runtime turned out to be built without optimization; fixed, crowded scenes run at 29.5 to 30 pictures per second.
Play to first frame: 17.7 s → 5.5 s - Everything around the game
- M15
The Quick Menu
NiXA's own menu opens over the running game: a three-finger tap, a menu button, the controller's Home key or Back.
- M16
Performance overlay and Capabilities
Live frame rate, frame time, CPU, GPU, memory and temperatures over the game. What the device cannot tell shows as “–” and is never guessed.
- M17
A whole Switch controller on the touch screen
Both sticks, the D-pad, all face and shoulder buttons, minus, plus and Home, laid out for the cover and the inner display.
- M18
The stop screen and Cloudseeker
When NiXA stops a game at something not yet ported, a screen says why. Cloudseeker, the opt-in diagnostics recorder, keeps each run on the device.
- M19
Saves in your own cloud
The Apple apps' Nextcloud save sync comes to Android: play on from the same save on every device. Conflicts are always asked, never overwritten unnoticed.
- M20
macOS, first part
The Mac game app gets NiXA's launcher with its Saves tab, the Quick Menu and the sync notice.
- M21
macOS, second part
The performance overlay, Capabilities and Cloudseeker on the Mac. iOS and iPadOS follow.
- Now: the second game
- Now
Mario Kart 8 Deluxe is in game
On the Galaxy Z Fold7: in game; runs slow, lighting glitches. The work goes on.
Source: the milestone reports in the repository (android/MILESTONE*.md). A date is the report's own where it states
one, otherwise the day the report was committed. Milestones 2 to 7b ran test code written for the port; no game was involved before milestone 8.
Built with AI
Developed entirely with AI
NiXA is and was developed entirely with AI. The code, the tests, the tools, the milestone reports and this page were written by AI coding agents:
CodexOpenAI
GeminiGoogle
ClaudeAnthropic
A human sets the course
One person owns the games and the devices, decides what comes next, and tests the builds on real hardware: the phone in the hand, the picture on the screen, the sound from the speaker.
The agents may not invent success
The project's rules for its agents: find the root cause, stop with diagnostics at anything unknown, and claim only what was observed. That is why the timeline above also lists the stops.
Tools
Starsearcher and Cloudseeker
Two tools that came out of the port: one looks at a game before and after it runs, the other at a NiXA app while it runs.
Starsearcher
Checks a Switch game against NiXA's Android backend before and after it runs on a device: which graphics functions, SDK imports and system calls the game's modules hold, what the backend does with each of them, and what the game actually called and where it stopped. It runs locally, reads game files without changing them, and its reports hold names and counts only, never game bytes.
Cloudseeker
Records how a NiXA app behaves while a game runs, on Android and the Mac: warnings, the place where NiXA stopped a game, crashes, frame times, memory and temperatures. It is off until the player turns it on and agrees, keeps everything on the device, has no network code, and leaves out saves, game files and pictures. The player exports a session as a ZIP and decides whether to share it.
Important
NiXA is an independent project. It is not affiliated with Nintendo, not made by or with Nintendo, and not endorsed or reviewed by Nintendo. Nintendo Switch is a trademark of Nintendo; game names and icons belong to their owners.
NiXA does not support piracy. It contains no games, game files, keys or firmware and downloads none of them. Use only games you bought and keys from your own console. Your files stay on your computer and are not changed.