Last time, I reported that I was fighting with Apple’s development ecosystem to automate the creation of a Mac port of my strategic leaf-raking business simulation game, Toytles: Leaf Raking
In the end, I wasn’t able to completely automate the creation of the Mac application, but my scripts do a lot more than they used to so I can spend as little time in Xcode as I can.
Sprints 2026-MJ_8, 2026-MJ_9, 2026-MJ_10, and 2026-MJ_11: Release SDL3 update version
Completed
- Ensure Mac version can still be built/deployed
In progress:
- Ensure Android version can still be built/deployed
My apologies if you aren’t interested in the technical, behind-the-scenes work, but this post is going to be a somewhat technical, behind-the-scenes post.
My goal was to automate the creation of a Mac version of the game and get it published on itch.io as quickly as I could.
I already have a deployment script that works for Windows and Linux, so adding the Mac port wasn’t difficult.
But I first needed the Mac port.
I was already using CMake to create an Xcode project. As much as possible, I tried to get my CMake configuration and scripts to create an Xcode project that had as much configured as possible. A long time ago I used to manually copy in my resources directory, which holds all of the images and audio files that I use in the game, but eventually I got the configuration to do that for me automatically. Similarly, I got my account/team information tied in so I didn’t have to manually specify that I wanted to use my account for code signing the project.
I still had issues with other things being a manual effort, though, such as creating a Universal binary, which can run on older Intel-based machines as well as the new Silicon-based ones. Last time, I had to create a set of SDL2 libraries on my Intel-based MacMini and another set using Mac in Cloud, then use something like lipo to combine them together into a “fat” binary, then build my project in Xcode using those fat libraries and making sure to configure the project to also be a Universal build.
But now my build scripts can create SDL3 libraries that are Universal binaries, and I can create a Universal app that I can test easily once the build is finished.
Unfortunately, I struggled to automate code-signing and notarizing. Between Apple’s documentation strongly encouraging using their GUI-based Xcode, rarely mentioning their xcodebuild CLI tools, and needing to dig deeply into the details of certificates and provisioning, something that Xcode’s manual effort handles automatically, I decided I had been working on this automation work for way too long and to cut my losses.
I made progress. I can create Universal libraries and a Universal app automatically, so I can quickly go from nothing to a program I can run and playtest. I can confirm that everything works, that it has the right permissions, and is packaged together properly. Archiving, notarizing, and exporting are relatively quick manual steps, and then I am finished and can upload my new Mac app to itch.io.
Next up was the Android build.
It was fairly straightforward to update my project’s build scripts. SDL3 provides an android-project directory, which I copy into my project, and then use CMake/configure to update files based on my project’s details.
I ran into problems running it, however. It seemed to keep crashing when launching the game.
Ultimately it came down to having an older version of SDL3. There was a mismatch between the android-project’s Java code and the C code related to SDLControllerManager, and it took me awhile to find it, but the discrepancy was already addressed in the latest SDL3 version. Once I grabbed the latest SDL3 and built it with my project, it finally ran successfully.
Then I had to update how touch presses were handled, which I think was potentially due to the high DPI of mobile devices. Basically, SDL3 touch events are scaled from 0.0 to 1.0, and I would multiply it by the screen width and height that I requested in order to identify where on the screen the touch event occurred.
But in high DPI mode, if you use SDL_ConvertEventToRenderCoordinates(), it scales to the screen width/height already. So I was basically taking an event’s coordinates and multiplying them by the dimensions of the screen a second time, which made it seem like the inputs were happening way, way offscreen. No wonder it seemed like input wasn’t working right!
So I ended the week pretty close to having a new Android version ready, but I wanted to test it some more to ensure that there weren’t any other quirks or surprises. Then I’ll work on the iOS version.
Thanks for reading, and stay curious!
—
Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!