Basile

Thx. Hopefully the users will like them :D

I could not resist adding variants for the differents GameCube colors. #BuildInPublic

Until now I managed 2 sets of icons, pre iOS 26 and iOS 26. Now with so much icons it becomes a pain. The render of iOS 26 icons on iOS 18 is not great, but more than 70% of my users are on iOS 26 so I think im going to drop those iOS 18 specific icons. #BuildInPublic

I'm not an icon designer (or a designer at all), but I think the last 5 new additions are nice. Maybe I’ll go for a purple background for the GameCube controller, and the PS1 might need a bit more contrast. #BuildInPublic

I need to take a break from testing. Going to work a bit on the new icons for the end of the day. #BuildInPublic

I think all code path are now performing the user data migration. Just need to test and test and test. Between normal usage, iCloud sync, iPad app, backup restoration, there is a lot. #BuildInPublic

As for the games ID it will be per game basis when accessing game detail. Since I kept TGDB Ids along side mine I can retrieve the corresponding one and update the local data. #BuildInPublic

Games user’s data migration is going well. I’ve opted for a local migration. For now my DB is a mirror of TGDB, but IDs of genres, regions, platforms, companies and games changed. So, on update I’ll seed the db with new data, and use mapping file to match the new IDs. #BuildInPublic

Played a bit of Zelda 1. How did I manage to finish this game when I was young. It’s so hard! 😅

I'm just procrastinating and I don't want to start working on user data migration. So scary.

I hate working with dates.

The biggest trap with LLMs (and I often start to fall for it), is the over engineering. It is so easy to add more and more, and refine, and expand.

One of my goal with mirroring TGDB, is to be able to do some cleanup on the data, and move from a flat listing with all the releases to one where various releases of a same game are grouped, which would be less of a mess. #BuildInPublic

Step 1 done. The app now works with the new endpoints, new models, that's a big step forward. Next, some adjustments and fixes due to the way sync stuff with iCloud. And next the big, world breaking, migration of existing user data. #BuildInPublic

For Games, the plan is « simple ».
- Update the code so the app works with the new endpoints and models (like for new users).
- Prepare data migration methods for existing users data.
- Cross fingers.
#BuildInPublic

Ok. The migration task of Games code for the new API, models etc.. is going to be wild. After so many years, I kinda of forgot all the weird and edge cases the app handles. #BuildInPublic

So today I made the first modifications to Games, so it relies on my mirror of TGDB instead of directly querying it. Still lots of work to do, but it is really nice to see it working. #BuildInPublic

So, I’m almost done mirroring the TGDB database, and I have a system to sync recent changes. Now I need to build the API that Games will use as well as the changes needed to the model, because I didn’t keep the same :) #BuildInPublic

But I also started working on missing releases, UPC etc… too much. When what I need is at least the same content as TGDB but with a better organization.

I’m wondering if what I’ve setup to migrate from TGDB is not over engineered. My main goal is to stop having duplicate entries and group those under the same game as different releases.

I always check the code Claude produce, but to be honest the more it is on something I don’t do often (like website, admin interface) the easier it is to let it do what it wants. But if it touches some Swift, my eyes are wide open!

Once it has enough data to be usable, I’ll replace TGDB in Games with it, and allow users to submit changes or entries missing. That should help.

And this is just for the games. I kind of have the same process for covers. But that’s a lot longer, since I’m aiming for quality.

It takes time. For each match I have an accuracy value, below 90% I need to review it. But the longest is the Japanese games, as the romanization is not always the same. Example, the SNES has 1749 games, with a lot being release in 3 regions. I had to check 60, and assign 400 myself.

I know I could just have get the TGDB data and try to clean them, but that it would still have been a lot of work, and no organizational gain. #BuildInPublic

The process is « simple », I get a JSON from wikipedia game list per platform (with titles, dev, publishers, release dates), it is then matched against the TGDB database. Once done I still need to manually match the one the process didn’t found or mismatched. #BuildInPublic

But this is a long process.😅 So far I have:
- Dreamcast
- Master System
- 32X
- Virtual Boy
- Nintendo 64
- WonderSwan (and Color)
- Jaguar (and CD)
- Famicom Disk System
And currently working on the SNES.
#BuildInPublic

At this time the app uses TheGamesDB, but I want to avoid depending on them too much. TGDB have region handling, but this need duplication, so I built a tool (thanks Claude) to help me consolidate entries, into a game + it's release. #BuildInPublic

I've started the « you won’t finish this in your lifetime » task of building my own video game database for Games. #BuildInPublic

I just prompt as much as usual, and my Claude Code sessions just fill in minutes. But I don’t want to pay more and I don’t want to pay for multiples products. I just want to have what I paid for. 😮‍💨