One reason I began writing this blog was to give myself a direction for the many projects I’m stuck working on.

And you know what? I gotta say that I’ve been more productive after my first posts than for the majority of last year. I hope to continue that, so today I have some nice updates to share with you.

New Mii Renderer Server

Like I mentioned in my last post, my two-year-old code for this has needed to be rewritten for a while. Since then, the list of reasons to finish this has just grown larger and larger.

Allow me to show you how I’ve been doing with this.

These are examples of some rendering features:

• Accurate Mii head models
• Wii U shader
• Proportional Mii body scaling
• Animations
• Headwear support

None of this is new, but it’s all wrapped into a clean C++ package.

Now here’s that same C++ code used in an example for the web.

• The WASM code is called from JavaScript, but this is not FFL.js.
• Small code size: under 200 KB.
  • For reference, Three.js alone (before any Mii code) is >700 KB.
• Very fast icon renders.
  • Apple M1: 4-8 ms
  • iPhone 6s: ~24ms
  • 2008 NVIDIA ION + Atom N270 netbook: ~96ms
    • This is still faster than studio.mii.nintendo.com.
• Asset size = ~960 KB.

Here is another example of that C++ library, but called from Python and C# code.

• These bindings were automatically generated by weaveffi.
  • It can generate bindings for JS (Web), Python, .NET, Node.js, Go, Ruby, Swift, and more.
• OpenGL 3.3 and ES 3.0 (2011) are supported, covering any modern device and OS.
  • My very own GLHeadless library is used to set up OpenGL without a window.
  • It should Just Work(TM) on servers as well.

By the way, note that this is not the same as my Fusion library.

• The Fusion library compiles directly to your desired language (JS, C#, Python) and prepares model data for rendering.
• This library/server is built as a native/unmanaged library with bindings for many languages, and performs full model rendering to an image.
  • For preparing models, this is still using the FFL decomp for accuracy/comparison purposes.
  • Later on, this will use my Fusion library internally. If you don’t understand any of the above, then it isn’t important to you.

What’s done?

Like you saw above, Mii rendering is more-or-less nailed down (despite me underestimating how long it’d take).

• Body scaling is working (without manual patching to raylib like before), and on the Miitomo body as well.
• Shaders are implemented in a modular way, with Wii U and basic materials to pick.
  • The rest are to be implemented, but I actually did put all material parameters into Fusion classes that I tested to work in JS.
  • In my opinion it should take no more than 2 days to add everything from FFL.js, including 3DS and Wii materials.
• Body models have finally been extracted cleanly from Wii U, Switch, and Miitomo.
  • I forked Switch Toolbox to export more formats, (which can be turned into a CLI later), covering Wii U and Switch models.
  • For Miitomo, I used the official PowerVR SDK and Assimp to make exports with more accuracy than the current tools, which I’ll release soon.
  • Model exports are so far pristine with further conversion to IQM, though Wii and 3DS will need more work. Highlighted in bold are practically the only major steps left for rendering to be on par with the old project.

Next, it’s worth mentioning that I experimented with making an HTTP server for the old solution in pure C++. It works great, and can be reused for the new solution to run conveniently in one binary.

The difficult(-ish) part

At this point, with rendering out of the way, you’d assume the hard parts are all done by now. But at the time of writing, I’ve been stuck on the part where this gets polished into a nice package for a while.

We know that we can create icons, but what will the interface look like? How can it fit all of the scenarios I need, old and new? This is what I’m trying to work through.

• Serving Mii icons via an HTTP server
  • Dozens of projects use my server already, and even MORE projects use Nintendo’s server.
• Obtaining the same Mii icons internally via the library
  • Ideally, you shouldn’t have to rely on a server. (I’m also struggling to maintain mine)
    • That benefits speed, scalability, and customization.
    • Web browsers can do this too, every visitor to your website has a GPU.
  • It’s really important to me that there is feature parity. It to be the same code, not just a port.
• Exporting 3D models of Mii heads and body models
  • Used by a handful of projects, as well as artists.
  • If not tied down to a library, it has huge potential in games (engines can import directly).
  • My new exporter is very fast, making it viable for many situations.
• Re-rendering the same model in succession
  • Multiple angles, multiple expressions, etc.
• Rendering with any arbitrary camera position + presets
• Potentially supporting animations
  • Probably individual frames.
• Accepting any Mii data format
• Adapting to future changes

In an earlier draft of this post I had a big list of people who’d legitimately find this useful right now, which I cut since it seemed boring. But trust me, it filled one or two pages. You do trust me, right?

Mii Fusion Rendering

These major parts make up the Mii “system”, and it’s what I’m trying to remake in my Fusion code:

1. Mii data (will discuss later)
2. Resources
3. Rendering

My biggest gap was with resource files, which provide shapes and textures. Like demonstrated in a previous post, I was able to parse some of these generations. However, all of them were in completely separate classes and required unique code to support each.

As a result, I began rewriting it all at the end of April. All formats now use a shared interface, so you can write one piece of code and access any of them. Let me show you:

Slightly shorter and older video available here

What you’re seeing here is my simple “shape viewer” in JavaScript.

• In case you didn’t catch it, my library supports every Mii resource format.
  • Wii (RFL), DS (NFL), 3DS (CFL), Wii U (FFL), Miitomo (AFL), Switch/2 (ShapeMid/High.dat).
    • According to hexkyz in the ReSwitched Discord, the Switch 2’s Mii shapes are identical to the original.
  • Most of these formats already had tools, but now they’re under one umbrella and work in many languages.
    • For the record, we had tools for: Wii (C# by Atlas, closed source), Wii U/Miitomo (Python: jaames, Abood), 3DS (Python by wwylele).
  • This is actually the FIRST tool that parses DS shapes! It only took 18 years.
    • Do you want them? Here they are, enjoy! NFL_Res-shape-arian.zip
    • There are some other problems with drawing DS Miis in a “universal” fashion that I may discuss later.

Now for textures, which I didn’t have last time, I ran an example in C++ to decode them for every major generation.

• Pointing out: the design here is low-level, which will be very useful for Miis in homebrew.
  • Specifically, the file reader (ResourceAccessor) and shape/texture decoders are separated.
  • This gives you the raw data to upload into the GPU if it’s compatible, or use the built-in decoder.
• Decoders output float[] for shapes, and RGBA pixels for textures.
  • Texture deswizzlers are small and ported from existing code (w/credits, of course 😅).
  • … In particular, the Wii U deswizzler was ported from 2200 lines of C++ to just 200 lines of code that runs 2× faster:
    • If anybody “in the know” is reading, it only works on FFL textures (R8/RG8/RGBA8) for now.

Finally, just for the heck of it, here’s one simple example that decodes shape data running in many languages.

• What it decodes is just the glasses shape data (which is a simple quad) from NFL (DS), NX, and FFL.
  • Last two are zlib compressed.
• To enable decompression in pure Fusion, I ported a zlib decompressor from C++.
  • I posted it here if you want, but please read below: https://gist.github.com/ariankordi/88029b5ef0760ef8b12acbc7e70f7f3e
  • The ONLY reason to do decompression in pure Fusion like this would be to build tests with zero dependencies, such as the one I showed above.
    • Otherwise, this adds bloat and I would not use it for an actual program.
    • Instead, I recommend simply running decompression outside of the Fusion code/library.

Isn’t that neat? Supporting all of these console generations means three major things:

1. Pixel-per-pixel accurate rendering for each generation’s Miis.
2. Homebrew that can render Miis on these consoles with the original assets.
3. Potential to mod these files (if I implement re-packing).

Now that resources are out of the way, let’s talk about actual rendering.

Mii Faces and Expressions!

In my last update, I demonstrated rendering shapes with Fusion, but not textures. What was up with that?

Previously I couldn’t even read textures out of the resource file, but now that I can, I have this to show you:

These are all of the Mii masks for every 3DS/Wii U/Switch expression, loaded from Fusion code. It’s drawn in less than 350 lines of JS.

What’s so special about my mask implementation, you (m)ask?

• Each part is drawn with 2D UV transforms instead of 3D transforms.
  • This is a tiny bit simpler, more efficient, and still 100% fully pixel-per-pixel accurate.
  • It allows drawing each texture on the mask shape directly, which is needed for GPU-less glTF exports.
    • Here is an example file for you that does exactly that: bro-inline-mask1.glb
    • Another example that trims the area around each mask part: bro-inline-mask2.glb
    • The important thing to notice is that there’s no intermediate texture in that model. That will be a huge simplification.
• All 19 expressions are implemented while maintaining the ability to load multiple at once.
• The entirety of it was reversed independently from nn::mii, rather than copy-pasting from the non-matching FFL decompilation.
• This was one of the last features needed in my library to reach feature parity.

While this probably doesn’t look impressive, especially since all of the expressions are just stored in a table within FFL, Nintendo implemented them in an interesting way.

Instead of just loading each new texture as you go, the Face Library has a fixed amount of slots for textures that vary by expression.

Here, have a horrible vibe-coded diagram of roughly…???? how this works. I know this isn’t that clear, but the main point is: even if many expressions use the same texture, it’s only loaded once.

This approach looks like “caching” or de-duplication, yes, though it’s all statically defined. That makes it annoying to implement, and I put it off for a long time because I wanted to be able to add new custom expressions easily without sacrificing this optimization. Until then, I simply implemented it as-is.

Unfortunately I’m not quite off the hook with these yet, because of these bastards. Somebody (me 😹) HAD to port all of the Miitomo expressions to the FFL decomp, but man, I’m regretting the way I did it. The 3DS/Wii U/Switch expressions should be built into the library, yes, but not these.

What this means for me is that I can’t “officially” fully replace my FFL fork until I come up with custom expressions, and then use THAT mechanism to implement Miitomo expressions. That will make them fully optional, as well as allowing anyone to add more expressions without changing the library.

Lol

Fun fact: the FFL decomp (or my modifications) got the wink direction wrong.

“Wink Left” expression in the FFL decomp (via FFL.js / demo-basic.html)

When implementing my new code, I noticed it disagreed with the decomp and insisted it was a mistake. Sure enough, after testing a real build of FFL in an emulator, that’s when I realized the decomp was actually always wrong about this. “Wink Left” created from Nintendo’s code (via NWF / nwf-mii-cemu-toy).

Gonna be real fun fixing every broken assumption I’ve made from that…

Bonus for You :)

I really want this stuff to get to a state where I can release it. Trust me, I hate it as much as (if not MORE than) anyone else when someone’s working on a cool project that they just keep holding back. At the same time, I hope you can understand when I say that I’ve been burned by releasing too much in the past. (will explain more later)

Until then, I still thought I’d throw The Reader a bone here. This is the HTML for that shape viewer I showed off earlier: 2026-05-23-mii-fusion-shape-viewer.html

This isn’t meant for anything more than just playing around with. You will notice that the JS is aggressively minified, and I kinda hate to be like that, but I was able to squeeze this down to just 30 KB isn’t that INSANE!!!!!

So enjoy, and look forward to the full thing. 🫡

Fusion Mii Data Library

Writing my own “good” Mii data library is something I’ve been planning for a year and a half, and it’s the reason I even began looking at Fusion.

Unfortunately, I always kept overthinking all the ways to approach it in the most un-compromised way. This led to no solution, which is the worst solution.

But in May, I ACTUALLY began developing a full library (using the Ghidra method) to achieve full decoding/encoding of all known formats, all in pure Fusion, working across many languages. Hooray. Here’s some code. The test that ran in this screenshot decoded and encoded various Miis in Wii, 3DS/Wii U, Switch, and Studio formats to verify it can decode and re-encode to the same bytes.

But Does It Actually Work

How do I prove to you that this is the real deal? Well, so far I was able to replace two existing libraries with the one I just created. Let me show you.

You won’t recognize this one at first, but if you’ve used mii-unsecure.ariankordi.net, you have run this code before:

• These are dozens of unit tests including 51 Mii conversion cases.
  • They cover decoding, conversion, and encoding with high branch coverage.
  • All tests pass with flying colors.
• I actually wrote these tests a year ago for an old JavaScript Mii conversion library made for my website.
  • I haven’t heard of any issues with it in a year.

My second example is for this browser extension, which includes Mii conversion and QR code features. By replacing the MiiJS library it uses with my own code, I reduced its size from 450 KB to just 61 KB with all* features intact!

If you’re confused about why I am showing both esbuild and google-closure-compiler (which is smaller) for mine, but not for theirs, keep reading.

Benefits of this new library

I know what you’re saying - that can’t be right, can it? All decoding, QR reading/writing, and all but Wii conversion? All in just 61 KB?

There are two core reasons, and Fusion is responsible for them.

1. Lack of bloated libraries.

   • QR codes and encryption libraries are intentionally left out of the main package.
     • You can use any library you want.
     • Your language may even have them built-in. Because Fusion works with them all, it’s not forcing you towards anything.
   • For my JS code, I use much smaller libraries:
     • qr.js (10K), qr-scanner (40K)
     • SubtleCrypto, a built-in encryption library.
   • These features ARE still supported, though it means you may have to write five lines of code instead of one.

2. Minimal/simplistic design.

   • Each Mii format has their own encode/decode function.
     • If you don’t use a format, the unused functions can get stripped in the build process.
     • But if you have a design like MiiJS where everything goes through one function, you have to include MUCH more code.
   • Structs are handled in a very simple way: raw byte/bit access.
     • No complex objects, no helper functions. It’s as minimal as you can get.
     • This style of code is so simple and portable, chances are you can copy-paste it into any random language. I did this with GDScript:
   • Because there is no reflection, Closure Compiler can be used.
     • Its most effective optimizations do NOT work on ~70% of JS code (like MiiJS) unless they follow its restrictions.
     • However, the way Fusion is transpiled makes its output always 100% compatible. So, you may consider this an “optimization”.

In summary:

• Not only did I replace another library with my own in the same program, sacrificing (almost) no functionality…
• The code is also 7x smaller
• It’s more reliable/type-safe, since Fusion supports TypeScript
• Is reusable in many other languages
• And is not based off of outdated guesswork.

If you want to call my bluff, check out my smaller version of MiiStudioMiiLoader downloadable here. It will only work in Chrome if you unzip then “load unpacked” with “developer mode” turned on.

Remaining challenges

You know when you start a project, complete 80% in a week, then suddenly like 3 months have passed and you still haven’t finished the last 20%? Yeah…

• Data verification: Not implemented.
  • I think there should be validation functions for each generation, so you know if it’s valid for a 3DS or for a Wii, etc.
    • But I’m sort of implicitly converting to Switch values when decoding.
    • I think I can handle it on a case by case basis, or only verify encoded bytes.
  • I also need to make a big enum for all failure reasons.
  • But I also want to have an enum for the type of Mii part in general.
    • This would allow Get()/Set() methods taking the type and value. This will be useful for a Mii editor.
    • ideally there should be just one enum for both of these.
  • I just have to lock in and spend a few hours on this.
    • Thanks to The Ghidra Method(TM), I was actually able to get away with generating a huge chunk of the library in a few days.
    • so I actually haven’t spent as much cumulative time on this as it seems.
• Wii conversion…
  • Round-trip decoding/encoding IS actually supported, but NOT downgrading newer formats to Wii.
  • Because Nintendo has never officially supported this conversion, it has to be made from scratch.
    • A certain library already does this conversion by using tables of handpicked downgrade values.
    • Maybe the replacements can be picked automatically based on the part outlines, I don’t know.
  • However, I definitely want the ability for a user to pick the parts and colors they want as well.
    • There should be a method to let the user know if that’s needed.
  • In addition, sadly my interest in the Wii is low.
    • it’s just a pain to get working. Does anybody actually like finding Wii remote batteries? IF THEY EVEN WORK?!
• Mii classes
  • When encoding/decoding, you have MiiVisualInfo and MiiExtraInfo.
    • Extra contains names and other non-visual sharing options.
  • The reason I split the two is to potentially simplify rendering code.
    • Decoding/encoding is possible without ExtraInfo at all.
  • This works well with low-level languages, but not as much with JS, C#, Python, etc.
    • The library can’t exactly return two new objects.
  • Anyway, what I’ll probably have to do is have a class that includes both.

Gets uglier the more I look at it. Who came up with this crap?! 😹

After I solve all these challenges, there’s one more anomaly that looms over me before I release the library.

The Struct Anomaly

As you know, I take accuracy very seriously. In order for the library to be more accurate than any previous attempt, I’ve used actual debug info and lookup tables extracted from the Face Library code.

However, I’ve decided that I must put all of these structures and tables into one nice repo before I release the library. I just have to.

This is one of those tasks I’ve been putting off for a little bit more than a year that probably won’t take more than three days, but, alas, I have to find the time.

One of the reasons I kept overthinking this task is because there’s now three formats for structures I’ve used, and they all have their own niche uses:

• C/C++ headers (.h)
• Kaitai Struct YAML (.ksy)
• ImHex Pattern (.hexpat)

What I thought I had to do previously was to choose one of these formats, and create a script that generates the others from a single definition. I even tried using struct-fu for this.

Eventually, I realized that I could just create all of the definitions one time, because there are only so many structures.

Or heck, maybe I don’t even need to. I already have a bunch of structures in all three formats sitting on my computer, so arguably, I just need to round up all of the files that I’ve already been sending to people on request and just post the darn thing already. Gah.

In Other News

There are some projects from others that I’d like to highlight and write about in this post as well.

TL:LTD Wi-Fi Transfers Reversed!

Do you remember that one game Nintendo released earlier this year? I think it was called, like… Tomodachi Life: Loathing The Dream?

Shortly after the game came out and before everybody stopped caring about it, I shared my thoughts on the game. My post basically came down to “okay but how can we hack it”.

Specifically, my sights were set on the local Wi-Fi transfer feature in the game. I handful of people begin looking into this alongside me, and I’m pleased to share that they have results!

This is Skyler’s experiment for transferring Miis between an unmodded console and a PC, which this video shows working pretty well. Source code is available here.

Another guy from Kinnay’s Discord, shatter9652, had also managed to get this working. His repo contains many miscellaneous tools that may be worth checking out.

With that exciting news out of the way, both of these people pretty much gave up on their ideas as soon as they got to this point. Effectively, it only works on Linux with no GUI. Didn’t take long for them to give up…

So, will somebody take the major step to make this useful outside of an experiment? Is there someone out there who can perform the Herculean task of porting LDN to C++? I don’t know. But it does use 802.11g/2.4GHz, which could make it possible on the 3DS!

I think I could speak for everyone when I say that interest in this game dropped sharply just weeks after the release. I never even got a chance to play it properly, since I didn’t see copies in store. The only reason I’m even bringing this up here is because… well, I’ve been writing this post since May. Whoops.

But if I’ve learned anything from this… “community”, it’s that somebody may care at some point. Maybe.

Oh And the Pokémon Thing

I was about to wrap up here, but between beginning this post and now, it’s probably worth noting that someone has done the exact same thing with local Wi-Fi but for Pokémon FR/LG! https://github.com/tornadus/frlg-ldn-trade

That project linked uses the same LDN tools as would be needed for Tomodachi Life. It does still need Linux and other complicated setup processes, but hey, someone made a video on it, so that may attract interest!

New Miitomo Revival: Tomiimo

Recently a new revival popped up for Miitomo, Nintendo’s Mii-centric mobile app that shut down in 2018: tomiimo.online. If you’ve never heard of this app, you can view the official website for it.

When I started hearing about this new project in May, it was very gratifying to know that a new person started to work on this.

But why would I care about a new revival of a 10-year-old Nintendo app, when there had already been one for 6 years?

What about Kaerutomo?

If you’ve never heard of them, Team Kaeru revives a handful of obscure Nintendo online services, and Miitomo is one of their four major projects.

However, their revival Kaerutomo is infamous for being unreliable and incomplete. As I write this, Kaerutomo has been down for 10 months. By the way, that followed a huge outage they had for the majority of 2024.

One example of a basic feature that doesn’t work is Miifoto. If you try to access it the way you normally would, the app freezes. You instead have to go through another confusing screen.

Another major feature that doesn’t fully work is QR codes. you can create and scan them, but it doesn’t preserve extra data from this game - Switch colors, personality, voice… they are all gone when you rescan.

The QR code as created, vs what it looks like scanned in. Yeah. It contains a 3DS/Wii U compatible section (reduced colors and no further data), and that’s the one being shown.

Kaeru Sucks

Throughout their outages, the owners of Kaeru have discussed stuff going on in their life making it hard for them to maintain it. Life is tough enough as it is, and the amount of kids begging them to bring Kaerutomo back surely doesn’t help things.

However, I get less sympathetic hearing this sort of thing when their source code is still private, even after they promised to go open source in 2024. My friends also never heard back from them when they asked for help.

By far the most annoying interaction was around QR code extra data.

Back in 2024 I really wanted to figure out how to scan these, and because Kaeru didn’t share any code or reverse engineering, I had to reverse engineer everything on my own. This includes:

• The QR code extra data encryption key
  • Also used for Tomodachi Life and Miitopia, I believe nobody else had found this before I did.
• Obfuscation for the game’s HTTP data
  • Because it turns out that the “extra data” was actually stored server-side.
  • This is exactly what stopped me from making my own revival back in 2016-18, by the way. If only.
• Data structure used for clothing, headwear, etc.

After all of this, I was able to spoof the server and get the app to accept the “extra data” that I sent back. It demonstrates how Kaeru could fix this feature.

After having this proof-of-concept ready, I sent a detailed report to the only developer who (didn’t) listen.

I didn’t even ask them to fix it. I even asked them to GIVE ME THE CODE, so that I could fix this FOR FREE!

And what do I get back for all of this? Absolutely nothing.

Two years later, a friend pestered them on my behalf about it again. I don’t have a screenshot this time, but I explained my case again and it was even worse.

They basically ignored what I was saying and only responded to what they wanted to, saying “a version 3 is being planned” (but you don’t even maintain the current one), “we intend on open-sourcing Mii QR generation” (known since ~2018), and “it’s probably safe to release the obfuscation code” (when I already did).

Teams like this actively hurt reverse engineering more than they help. Seriously, shame on them for not releasing dumps or code.

Enter Tomiimo!

In contrast to Kaerutomo, Tomiimo seems quite lively. New features are being added regularly, and it’s committed to achieving as close to 100% functionality as possible.

The (seldom-updated) progress seems very promising!

Mitch, the author, is taking many suggestions from the community, and has also promised to release the source code.

Of course it’s just a promise, but I trust it a lot more than the guys who couldn’t even acknowledge the bug I was going to fix for them, if only they could get over their arrogance and hand the code to someone who knows what they’re doing. GOD. sorry

Many who are active on the Discord have been invited to test it, and I’ve heard good things about how it’s going. I’ve seen screenshots of more features working than I’ve seen in Kaerutomo, such as the comments section.

And of course, according to them “nothing is paywalled”. This is a nice contrast from how Kaerutomo’s “beta” (the only way you can play Kaerutomo right now) requires subscribing to their Patreon.

Now he’s also talked about not wanting many screenshots or footage of testing coming out, which is… weird but I can get it. That means there isn’t that much more to say, other than some miscellaneous thoughts surrounding it.

• Mitch has been a pretty mysterious fellow. This project came out of nowhere, and I don’t know if he has a GitHub profile or any other history. Quote when asked what inspired him.

Mitch says outright that he isn’t a Mii fan.

• There’s this library I released a while back (in Fusion! 🥰) for handling the game’s obfuscated HTTP traffic, a major piece needed to reverse engineer it: https://github.com/ariankordi/SakashoObfuscation
  • It is and was a great use for Fusion, and I’d be delighted to find out he ended up using it.
  • (FWIW, the app DOES have more obfuscation for e.g. the URLs themselves in libsakasho.so, and he’s said to have used Ghidra before, so I’m sure this… actually wasn’t as big of a deal as I made it out to be, oops)
  • According to him, he did use it at some point but not anymore. At least it wasn’t useless, I guess!
  • There’s also some code he needed for encoding the Switch CoreData format which he just seemed to come up with without asking me or anyone else…
• I’m really, really looking forward to seeing and contributing to the code, which isn’t out as of writing (3 months in).
  • Understandably, Mitch has been waiting it out.
  • I was a bit weary about QR codes for a bit there, as he made a choice I disagreed with.
  • Ideally I want the Miitomo QR extra data to be self-contained, as the “extra data” is currently stored on the server. I’d probably use eFFSD or similar.
    • That way you can create/read QR codes for Miitomo from other apps, without involving an external server.

My ideal, “REAL” future of Miitomo?

This is a game I’ve been interested in for a long time, and tried reversing since the very beginning. I’ve even had HTTP dumps of the game dating back to 2016:

I felt I had enough experience to clone the backend (like I did with Miiverse, SplatNet, NNAS kinda), and by now I’m familiar with decompilation enough to figure out the harder parts like for the obfuscation and QR encryption.

This begs the question, why did I never begin working on my own revival? Well, Miitomo has aged a lot. It’s over 10 years old by now, and doesn’t work on any modern devices.

• It crashes on iOS 16 and higher, meaning you need a device on from 2016 to use iOS 15.
  • There’s a fix I tried here (Kaeru Discord), but this didn’t work on iOS 17.
• The Android version is 32-bit, so recent devices may not run it natively.

But ever since I reversed Miitomo rendering, knowing we’ve had the ability to extract the game’s assets, and even seeing the Mii voices get reversed… can’t we just make “our own Miitomo”?

That way, we can do whatever we want with it. It can run in a browser, and connect to other social media platforms. After all, I’ve always yearned for the “Twitter with Miis” experience… 🤤

That being said, I know that a revival is harder to get wrong than a remake (unless you’re Kaeru).

How often do Nintendo fan projects actually look and feel like the real deal? It’s more of the exception rather than the rule. All you need to do is search “Mii” on ROBLOX to find the crap people are willing to put out.

At the end of the day though, the app DOES need a revival available to at the very least preserve its history, so that’s that.

Anyway

If you want the latest on Tomiimo, I recommend joining the Discord linked on tomiimo.online.

Will there ever be a true Miitomo decomp/remake any time soon? Well, I’m not holding my breath for it to happen. However, I hope that the more I develop, the closer we can get!

And of course, I wish the best of luck to Mitch. Despite my cynicism here, this is a lot to pull off for one guy - especially one that seems? at least a little bit? foreign to the scene. here. Whatever you want to call it.

Conclusion: When is this stuff coming out?

Mii Fusion Data Library

• I estimate a few days of remaining features/fixes are needed, though, most challenging parts are ahead of me…
• Like mentioned earlier, that struct repo needs to be created and thrown on GitHub before I release this. I’ll probably have to force myself, but.. I think I can do it…
• A major piece for me to figure out is how you release a library in Fusion to begin with.
  • We’re definitely publishing builds for each language, but will they be in the main repo? Separate repo? Releases?
  • Am I going to create packages for every language???? 🙈🙈🙈
  • May also need to create CLAUDE.md or other such files, as agents don’t know what Fusion is.
    • My worst nightmare, which I almost saw happen, is for someone’s agent to misinterpret and rewrite all code instead of using the existing port. AAAAA
• Even with all of that “administrative” work over with, the last major part will be creating some small apps around this.
  • What I really want are small tools for the command line and in HTML/JS. They’d let you use features of the library.
  • With vibe coding in the picture, it actually shouldn’t take more than a couple of days for a prototype.

If I had to give an ETA, let’s say 2-3 months. None of this is “hard work”, just a lot for me to process.

Mii Renderer Server Rewrite/Library

• This is probably the closest to finished. A week or two of effort will bring it on par with the old server.
• With rendering being more-or-less fully implemented, what’s left isn’t necessarily on the code side. Rather, I need the discipline to ACTUALLY decide the interface.
• My next step for this project was to vibe code my way to completion.
  • This will undoubtedly produce code that I hate, but it’ll at the very least give me something to work with.
  • What would help a lot is to take existing applications and try replacing their existing rendering with this, kinda like I did with the data library.
• Where I get weary is that I DO have a dependency on some Fusion code in this. So umm…
  • Not sure what to do about this yet. Waiting longer to publish the other will undoubtedly hurt more than it helps…
  • I guess I could ship the transpiled C++ without the original source? Not sure.

I would be deeply disappointed in myself if this weren’t out in 2 months.

Mii Fusion Rendering Core. Thing

• This is the least ready of all three. Really, it’s the most tech demo-y.
• Like the data library I’ll also need to figure out how to package this, but there is another repo I have to publish that I lightly touched upon at some point.
  • Thankfully, that repo I call “r2-bintable-extract” is already in source control and much more ready to release.
• By far the biggest blocker is that I 100% NEED to see this in action alongside FFL.
  • This will help me verify accuracy, so that it’ll actually be a viable replacement. Not something that’s worse.
  • Using this in a real program will also help me… (groan) design an interface.
    • Yes this will be another inevitable time sink, but I want the Fusion part to be designed in a way where the user has to write as little of their own code as possible.
    • Any simplifications I make along the way may break it, so that’s where the FFL comparison comes in.

There’s also some extras that would be nice but are not mandatory:

• I’d love to have the Mii model exporter working in Fusion.
  • It was the perfect pitch for the library, the “Mii to Model in any language” dream I promised/proved in May 2025.
  • For me to want this in Fusion WOULD require the C++ version to be in a good state. So if I didn’t have enough circular dependencies, that’s another. 🫠
• Another great thing to have would be the ability to edit/re-pack resource files. Then the resource library would be a LOT more useful!

With all that being said, I wouldn’t be surprised if 1.0 is 4-5 months away. :(

Reality is harsh. I always imagined releasing my Fusion data + rendering code together as the “ULTIMATE Mii Solution!!!!!!!!!!”, hitting people with this epic repo.

But I really can’t be waiting for too much longer, so when the repo is made public, it’ll be a little watered down until rendering is ready. Oh well.

(P.S., I still don’t know exactly what all of these will be called.)

Open source? Can I use it?

Of course you can! Everything I’ve shown off here will be fully open under a permissive license (something MIT-compatible), when I’m ready to.

If it’s useful to you, please use it. If not, then don’t. This goes for everything else I’ve published, and it will never change.

But. There’s an internal struggle inside me surrounding this project.

The Release Dilemma

Ever since last year, the idea of releasing any new code has made me uncomfortable. Why is that?

Something I began seeing is people taking what I wrote and running with it, and in some cases without giving back. In other words, I’ve been ripped off.

What I saw were a couple of apps, ones that I’ve had similar ideas of building, made in ways I didn’t like. Hopefully you can picture an example.

As humble as I try to be, I have pride in what I’ve been able to accomplish. I may not have done all of the work, but I’m not afraid to say that a TON of Mii projects wouldn’t have happened (or turned out as well as they did) without my work.

From my perspective, seeing someone take something I worked hard on and apply it to their (in my opinion) subpar creation, is something that kept rubbing me the wrong way.

Why I am Wrong

I’m afraid to admit it, but this struggle eventually manifested as anger towards a couple of people and their projects.

As a result, they developed this disdain towards me. They started thinking “we need to replace his code with ours”, which put more pressure on me to make my new libraries as good as I could make them (hence Fusion ☺️).

What usually happens with the “rewrites” these people do is that they are always worse than what they replaced. I have not once been impressed when this happened. But, you can’t control what others do.

Those people end up with a slightly worse product, and I end up worse off because I didn’t have anything to do with it. I lose the trust of others, and it brings me one step back from being a reliable “authority” on Miis.

This leaves me looking like a hypocrite: I say that I’m a believer in open source, that any and all software should be free to build on. But the moment it’s “MY” work, I start to be really particular about it. You can’t have it both ways, and this is something I need to let go of.

A lot of what I’m mentioning here is just plain immaturity that I’ll have to get over, but there is another nuance here as well.

So, what now?

The reality is: over the past year and a half, I’ve had barely anything to show for what I’ve worked on. No new tools, no site updates, not even any JSFiddles.

Wouldn’t you liked to see more fun experiments from me? How about my take on a Mii editor? (I’m going to write an article soon on that topic, so stay tuned.)

My real problem isn’t that the code is being swiped left and right. It happens, but the actual solution is for me to do more.

Spending this long on just libraries, rather than something people can actually point to and use, has been making me lowkey miserable. It also slows progress due to having lower motivation.

This is a cycle that has to end soon. I haven’t quite worked myself out of it yet, but I know that the top projects I have in mind are absolutely finish-able before the end of the year if I put my mind to it.

What does that mean for you, the reader? This time around, I really don’t want to just release the library bare and watch people go wild with it. I would want to make at least a couple of useful things with it before I do.

---

Conclusion

At the end of the day: “Those that can, do. Those that can’t, complain.”

And what have I been doing this whole time? 😁

In all seriousness, if this post was interesting, I’d appreciate any comments. Thanks!

---