A preserved copy. pokopia-native was made by xFractals (MIT, see LICENSE). The original repository and its author's GitHub account are no longer on GitHub (November 2026), so this copy keeps the last version that was available, 3 November 2026, with all of xFractals' commits, so that Hermit can keep offering it as a Pokémon Pokopia build. Only the gameplay screenshots and the demo video were left out. Nothing here is new work: the README below is the author's own, and support questions are best taken to Hermit's issues.
I got Pokémon Pokopia (the Switch 2 game) running natively on my Mac and on my iPhone. Not through an emulator: the game's own code runs on the Apple chip, and the graphics go through Metal. After a lot of work on the shaders it looks exactly like the Switch 2. I lined up screenshots from the Switch 2 against the phone, scene for scene, and could not tell them apart. Shadows, clouds, time of day, the lot.
This repository is the tool that lets you do the same with your own copy of the game. It takes your dump, and on your Mac it builds a Mac app and an iPhone app. Everything that comes from the game is created on your machine and stays in your build folder. Nothing from the game is in here.
This works for both versions 2.0.0 (v327680) and 2.0.1 (v655360) as of 11/3/2026
Also, if you do not have a Mac to build the app with, no worries; there is a Windows Builder as well. It will create the IPA the same way a Mac would.
Before anything else:
Please Please Please Please do not share game files, this is for your own games files only and that is the intention it was built with.
That means: do not upload your dump, do not upload the build folder, do not upload the app or the IPA this makes (they contain the game), do not upload shader caches or recorded shaders (they are pieces of the game too). If you want to help someone, point them here. They need their own Switch 2, their own copy, their own dump. The tool checks the dump is the right version and refuses anything else, and it needs no keys of any kind. Keep it that way, and this stays up.
Hey guys, I really hope you enjoy this. I just have to give a massive shout-out to the people at NxNative, this wouldn't be possible without them. I'd never tried to do any of this until last week, when they went viral, and once I found out, I kept going. This all started after 0x2593 posted their fork of Eden for NS2, shout out to them as well, that was a great help for getting this going. After running the first emulation of Pokopia, I just knew I needed to fix it and put it on my phone and Mac. Right now all of the PC emulators with Pokopia have issues with the shaders. My work on this native build allowed me to dig deeper and fix all of those issues. If you want to play emulated Pokopia with Eden, that's my other repository "pokopia-fixes" (https://github.com/xFractals/Eden-NS2), which is a fork of https://github.com/0x2593/Eden-NS2. Go check it out if you want, hopefully it gets merged into main soon. Anyways Enjoy!
Also, if you find any bugs, please feel free to let me know or submit a PR. More than happy to take a look. I've played up to after the first wake-up and encountered zero issues.
- A Mac app. Double-click, press Play, it runs. Saves live in your Library folder like any Mac game.
- An iPhone app. The game runs natively on the phone, full quality, 30 fps (the Switch 2 runs this game at 30 in handheld too). There is a catch about Apple developer accounts, explained below. Read it before you get excited.
Both are built from your dump by one script, nxs2.py. The first build takes about an hour, nearly all of it the
Mac compiling 3,800 shaders. After that, rebuilds take a couple of minutes.
- A Mac with Apple silicon (M1 or newer) and roughly 20 GB of free disk. The game's code is arm64, so an Intel Mac cannot run it. The Mac does the building for the iPhone too, or a Windows PC can (the last item here).
- Xcode 27 installed, with its command line tools and the Metal toolchain (Xcode → Settings → Components). For the
iPhone build you also need the iOS platform from that same screen, and
xcodegen(brew install xcodegen). - Python 3.12 or newer:
brew install python@3.12, thenpython3.12 -m pip install "capstone>=5,<6" lz4 fonttools pillow(Pillow only for the app icon). - The .NET 10 runtime (the shader translator is .NET):
brew install --cask dotnet-sdk. - Your dump. The game's files as your dumping tool wrote them, with the update:
A folder that holds
<your folder>/updates/<version>/exefs/ main main.npdm rtld sdk subsdk0 <your folder>/updates/<version>/romfs/ LD_C0_R.BIN LI_C0_R.IDX motor_asset_re/ movie_asset/exefs/andromfs/directly works too. Two updates of Pokémon Pokopia (title0400A3A01EE4C000) are supported, and the tool tells which one you have from the build IDs: v327680 and 2.0.1 (v655360). Both get everything, including the mouse and drag look. The base game alone is not enough, and another version will not build until it is added, because the patch recipe and the camera address are per version. - Copy the dump in binary mode. If you move it off the console with FTP, set the transfer type to Binary
(FileZilla: Transfer → Transfer type → Binary). The default "auto" mode treats files without an extension as text and
quietly drops bytes from
main,sdkandsubsdk0; I lost an evening to that. The tool checks for it and tells you. - For the iPhone: see the next section.
- No Mac? A Windows PC builds and signs the iPhone app alone: docs/WINDOWS.md (one play session on the phone before the title screen draws, see "No Mac?" below).
python3.12 nxs2.py doctor (or the window's Check tools button) checks all of this and tells you how to get whatever
is missing.
Pokopia is a big game. It reserves 11 GB of memory address space and actually uses several GB of it. To let an iPhone app do that, the app has to carry two Apple entitlements: Increased Memory Limit and Extended Virtual Addressing. Apple only grants the second one when the app is signed by a paid Apple Developer Program team (the 99 a year one). An app signed with a free Apple ID, through AltStore, Sideloadly and the like, installs fine and then stops at start-up when the game cannot reserve its memory.
I happen to have an Apple developer account, so I sign my build with my own team and never needed anything else. I have not tested any workaround. If you know one, something that signs with a profile that carries that entitlement, you are free to try it and I would like to hear whether it worked, in the issues. But I am not going to tell you it works when I have not done it myself.
With a paid team, the flow is: nxs2.py build ... --xcode --team-id <your team> then nxs2.py sign, and the signed
IPA installs over USB. Your Apple ID has to be signed into Xcode once and your phone registered on the team (Xcode does
that itself when the phone is plugged in). The details are in docs/IPHONE.md.
Memory on the phone itself matters too. The game uses a lot of it. I run it on an iPhone19,4 on iOS 27.2. If your phone has less memory than the recent Pro models, expect trouble.
There is a window and there is a command line; they do the same thing.
The window. Clone or download the repository, then double-click Pokopia Native Builder.app on the Mac
(Pokopia Native Builder.cmd on Windows). Press Setup once, choose your dump folder, tick what you want, press
Build. The stages scroll by in the window with the elapsed time; Refresh shaders is the refresh step explained
further down, Open build folder shows the outputs. If the app will not open, it tells you what to install (Python
3.12 with Tk: brew install python@3.12 python-tk@3.12). A clone opens directly. A copy downloaded with a browser is
blocked the first time, because the app is not signed by a registered developer: try to open it, then System Settings →
Privacy & Security → Open Anyway (or once in Terminal: xattr -dr com.apple.quarantine "Pokopia Native Builder.app").
The command line.
git clone https://github.com/xFractals/pokopia-native.git
cd pokopia-native
python3.12 nxs2.py setup
python3.12 nxs2.py build "/path/to/your/dump folder" --mac-app --ipasetup fetches nxnative (the host this runs on, more below) at the exact commit this is made for, applies the Switch 2
patch to it, and builds the shader lowering tool. About a minute.
build does everything else. It creates a build folder beside your dump (<dump folder>_native; --out names
another place), and goes through these stages. If it stops or you stop it, run it again and it continues where it was.
| Stage | What happens | Time on my M4 |
|---|---|---|
| extract | your ExeFS copied, the RomFS files packed into one image (6 to 7 GB) | seconds |
| rewrite | the game's three code modules rewritten so Apple's kernel can run them (nxnative's patch_nso.py) |
20 s |
| host | the Mac host compiled with this game's profile | 15 s |
| corpus, lower, package | 4,012 shader programs found in the game files, lowered, packaged with their tables | 25 s |
| chain | the Metal compile of every shader for the Mac and the phone | 30 to 45 min |
| outputs | the Mac app, the IPA, or the Xcode project | 1 to 3 min |
Outputs land in <build folder>/out/:
Pokemon Pokopia.app: the Mac app. Double-click it, nxnative's settings window comes up (handheld or docked mode, frame rate, upscaling), press Play. macOS asks once whether to open it (right-click → Open), because it cannot be notarized: it maps the game's code as executable, which Apple's hardened runtime does not allow. Saves and logs go to~/Library/Application Support/nxnative/0400A3A01EE4C000/and~/Library/Logs/nxnative/. The game files inside the app are APFS clones of the image, so the app does not cost you another 6 GB on the same disk.PokemonPokopia-unsigned.ipa: the iPhone app without the game files (they go to the phone separately, once; it takes three minutes over USB). Or, with--xcode --team-id, an Xcode project to sign with your team. Again, docs/IPHONE.md.
Use --no-ios if you only want the Mac: it halves the compile. python3.12 nxs2.py run "<build folder>" plays straight
from the build folder in a window, which is handy while you are fiddling with things.
The app icon. Out of the box the apps get the blank default icon, because the game's own icon isn't part of a dump.
python3.12 nxs2.py icon "<build folder>" makes one from your game: on a Mac it starts the game on a copy of your save,
takes a picture of the title screen and cuts the Pokopia logo out of it. It needs a save that is past the game's opening
(play a little with nxs2.py run or the Mac app first, or point it at one with --save <folder>). If you prefer, give
it a screenshot of the title screen from your Switch 2 (Capture button):
nxs2.py icon "<build folder>" title.jpg. Then build again with the same command; it only repacks the apps.
A Windows PC can build the iPhone IPA (not the Mac app, and it cannot run the game: the game's code needs an Apple chip).
It uses the tools nxnative's Windows port put together: Apple's own Metal compiler for Windows for the shaders, LLVM with
the iPhone SDK for the app. The same window and the same commands, --ipa only. What to install and how to get the SDK
is in docs/WINDOWS.md. Signing still needs a paid team; the window signs on Windows too, with your
certificate (.p12) and development profile (Sign IPA, see docs/WINDOWS.md).
I tested the whole Windows route on my iPhone: built and signed on my PC, it plays like the Mac-built app. The one difference is that a PC cannot run the game, so it cannot record the shaders the game makes while it runs (next section). Your first run on the phone does that: the title screen is black apart from its text until you have played a few minutes, pulled the recordings over and refreshed once. docs/WINDOWS.md has the exact steps.
Here is the one thing about this port that is not just "build and play", and I want to explain it properly so nobody thinks their build is broken.
A Switch 2 game ships its shaders compiled for the Switch 2's GPU. They have to be translated for Metal, and that translation cannot happen on the fly on a Mac or a phone with this chain; it is done ahead of time, on the Mac, during the build. That is the 30 to 45 minute stage. The build finds every shader in the game's files, 4,012 programs, and translates all of them. So far so good.
But Pokopia also builds some shaders itself while it runs. They are not in the game files anywhere; the game makes them on the fly, apparently as it needs them. I know of 140 of these so far on 1.0.5, from the opening, the character creator and the first area, and 2.0.1 makes 14 more of its own (154 in all). A fresh build cannot contain them, because there is nothing to take them from until the game has run. When the game asks for one that your build does not have, that draw is skipped: the game keeps running, but that one effect or object is not drawn. Nothing crashes. Be warned though: the title screen itself uses about 20 of them, so on the very first launch it is black apart from the version number and "Settings". The music plays and A still works. That is this, not a broken build, and it is gone after the first refresh.
What the build does about it: the apps record every such shader the moment the game makes it (they have
DM_NVN_SHDUMP on by default). Then you run
python3.12 nxs2.py refresh "<build folder>"which finds the recordings, translates the new shaders (a couple of minutes, not another hour), and rebuilds whatever
outputs your build folder has: the app, the IPA, the Xcode project. The Mac app's recordings are found by itself. The
iPhone's have to be pulled off the phone first with tools/phone_pull.py (two commands, in the iPhone doc). Then
reinstall and carry on. Repeat when you reach new places and notice something missing. In my experience, after the
opening and the first area you have the lot.
The build tells you where you stand: shaders: 3813 from the game files; 0 of the 140 known run-time shaders right
after the first build, and after a refresh with a full set of recordings 140 of the 140 (on 2.0.1: 154 of the 154).
The known list is profile/0400A3A01EE4C000/runtime_keys.tsv; it holds hashes only, so you can see how far you are,
and no code. The ones only 2.0.1 makes are marked there, so a 1.0.5 build is not counted short for them.
If you find run-time shaders beyond these, your refresh handles them exactly the same way. Tell me about them in the issues, with the count the build prints, so the list can grow. Do not attach the recordings; they are game code.
The game only turns its camera with the right stick, so out of the box a mouse or a finger can only fake holding a stick, and that feels like a console. I wanted it to feel like a PC or a phone game, so the build now has real look controls:
- Mac: click the game picture and the mouse is captured. Move it to look around; left click is A, right click is B, the middle button resets the camera. Esc gives the mouse back. Keyboard: WASD moves, J K U I are A B X Y, Q E are L R, Z C are ZL ZR, Return is + and Tab is −.
- iPhone: drag anywhere on the right half of the screen that isn't a button, and the camera follows your finger.
Sensitivity and invert are in the app's launcher under Controls ("Look sensitivity", "Invert look up and down"),
or in env.txt as DM_LOOK_SCALE (1.0 = default) and DM_LOOK_INVERT_Y=1.
How it works, because it's not just "mouse = stick": faking the stick felt laggy, since Pokopia's stick tops out at 110° per second and ignores anything below about half tilt. So the app found where the game keeps its camera's angle in memory and sets it directly, every frame, right before the game draws. Moving the mouse or your finger a given amount turns the camera by exactly that amount (measured to a hundredth of a degree), with no speed limit, no smoothing and no drift after you stop. Touches and mouse moves are time-stamped, so every frame gets an even share of the movement and a steady pan stays steady. If the game ever takes the camera over, the app falls back to steering the stick for that moment.
The app reads Documents/env.txt on the phone at start, one KEY=VALUE per line, and the build writes sensible defaults.
The ones worth knowing:
| Switch | What it does |
|---|---|
DM_FPS=30 |
frame-rate cap. 30 is the build's default and what the Switch 2 does in handheld for this game. 60 runs hotter. |
DM_OPMODE=0 |
handheld mode (default). 1 is docked: the game picks its higher resolution. |
DM_RENDER_SCALE=0.8 |
render at a fraction of the game's resolution, 0.5 to 1.0. Cooler phone, softer picture. |
DM_TOUCH_AUTORUN=1 |
the touch stick makes you run when pushed to its edge. My addition; I like it. |
DM_LOOK_SCALE=1.5 |
look sensitivity for drags (and the Mac's mouse), as a multiple of the default. Same as the launcher's slider. |
DM_LOOK_INVERT_Y=1 |
drag up to look down. |
DM_SHOW_FPS=1 |
frame counter on screen. |
The phone gets hot. At 30 fps mine reaches iOS's "serious" thermal state after about six minutes of play and stays
warm. DM_RENDER_SCALE=0.8 is the first thing to try if that bothers you.
- The host is nxnative, a project that runs Switch games natively on Apple systems: it rewrites the game's executable so the Apple kernel accepts it, provides the Switch OS services the game calls, and maps NVN (the Switch's graphics API) onto Metal. It did not know the Switch 2 at all. My changes teach it the Switch 2 side of things: the newer SDK's system calls and services, the NVN2 entry points and texture layouts, the Switch 2 shader format, and a translator fix or two. They are one patch against a pinned nxnative commit (host/UPSTREAM.md).
- Switch 2 shaders are a newer GPU instruction set than nxnative's shader chain understands. The
Eden-NS2 emulator has a decoder for them that lowers them to the older
instruction set, and
ampere-lower/here is a standalone build of exactly that piece, so the rest of nxnative's chain (the Ryujinx translator, SPIRV-Cross, Apple's Metal compiler) can take over. While getting the picture to match the console I found four bugs in that decoder (wrong colours, missing sun and cloud shadows, a crash); they are in a pull request to Eden-NS2, and this tool carries the fixed code. profile/0400A3A01EE4C000/is the game's recipe: identity and build IDs, the memory layout the game needs (it wants 11 GB), where in the files the shaders are, a handful of hand-made translation answers, the known run-time shader keys, and the entitlements. Numbers and hashes; no game content.
- Every stage writes its full output to
<build folder>/logs/<stage>.log.nxs2.py -vshows it live. nxs2.py status "<build folder>"says what the folder has and what it still lacks.- A different Xcode than the one nxnative's lock names (27.2) is reported, not refused: the build uses your Metal compiler and keeps its libraries apart. Mine is 27.0 and it is fine.
[RED] shader <key> is not in the shader mapin a run log is a run-time shader, see above, not a fault.- Open an issue with the stage, the last lines of its log and your Mac/Xcode versions. Never attach game files, build folders or recordings.
Everything here is MIT except ampere-lower/, which is Eden-NS2 code and stays GPL-3.0-or-later (its own LICENSE and
NOTICE.md are in that folder). The nxnative and Ryujinx code that host/ modifies and builds keeps their MIT notices,
reproduced in host/NOTICE.md. LEGAL.md is the full statement of what this repository
contains and never will, what the tool does not do (no decryption, no keys), and the trademark note: Pokémon and
Pokémon Pokopia belong to their owners, this is an independent fan project with no affiliation to Nintendo, The Pokémon
Company or Koei Tecmo, and the screenshots above are my own captures from my phone.
Thanks to the people behind nxnative and everything it is built from (d2r-mobile, Ryujinx, SPIRV-Cross, glslang, Capstone, lz4, fontTools, XcodeGen), and to Eden-NS2 for the Switch 2 shader work. I did this port with a lot of help from an AI assistant (Claude), over a couple of very long weeks, with Switch 2 footage of the game as the reference for every picture.
And once more, because it matters: your own copy, your own dump, your own build. Please do not share game files.