Freshly Squeezed Progress Report – Xcode/iOS Woes and Demoing in Public

In last week’s sprint report, I was investigating problems with touch input related to some incompatibility introduced by Android 11 as well as figuring out why the latest SDL2 version forced me to change how I build it for iOS.

I continued to investigate the iOS build in this past week’s sprint.

Sprint 23: Make publishable

Planned and Completed:

• Nothing. B-(

Not completed:

• Defect: game seems unresponsive on main menu screen (Android)
• Defect: game plays in portrait mode instead of landscape (Android)
• Create iOS build

The above summary doesn’t indicate what I actually got accomplished, which were some subtasks under “Create iOS build.”

Notably, I learned a lot about why things are different. I mean, it’s still not clear on the SDL2 side, but Apple recently made changes due to their new M1 chip architecture.

In the past, I used a script which took libSDL2, libSDL2_image, libSDL2_mixer, and libSDL2_ttf, built them for multiple architectures, and combined them into what’s known as a “fat” universal binary.

So whether I am running my app in the iOS simulator or on an iPhone or iPad, it just worked.

Except the way that fat universal binary was created was to smash a bunch of different symbols for different architectures together, which worked fine so long as you could be sure that symbols for one architecture were different for another.

And with M1, which is ARM-based, that’s no longer the case. Now there are two different ARM-based systems possible, and lipo, the tool that combines them, won’t do it:

fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: build/Release-iphoneos/libSDL2.a and build/Release-iphonesimulator/libSDL2.a have the same architectures (arm64) and can't be in the same fat output file

This is new as of Xcode 12.3, apparently. Or more accurately, it’s now being enforced, as it turns out that the way I was doing it (and many others, apparently) is not supported and hasn’t been for some time. Whoops.

So now my perfectly fine build system is no longer perfectly fine and I need to investigate.

And I know it isn’t that new to hear, but I hate working with Xcode. Ask me how many times I tried to change something like a library search path (which is annoying enough since there is no mechanism to find the path within the UI) and found that a big part of my configuration changed with no way to revert except to start over.

But I learned about Apple’s proposed solution of creating an XCFramework, and I spent time trying to figure out how to adapt my script to create one of those instead.

While I was at it, I realized that the way my build scripts worked wasn’t even taking advantage of the SDL2 framework I put together. I must have found that the framework was frustrating to figure out how to get Xcode to find and so I just pointed to the individual libraries instead of the single SDL2 library I bundled them all into.

Anyway, I found that I still struggled with getting the app to build with the new XCFramework, possibly because while SDL2 has a scheme for building a framework, the related libraries don’t.

After a few false starts in which my build scripts were still trying to find the individual libraries, I did manage to get to it to build using the XCFramework by manually adding it in Xcode since CMake doesn’t know what an XCFramework is yet, but then I get linker errors related to joystick-related code:

Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_CHHapticDynamicParameter", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticEventParameter", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_CHHapticDynamicParameterIDHapticIntensityControl", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
"_CHHapticEventParameterIDHapticIntensity", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticPattern", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_OBJC_CLASS_$_CHHapticEvent", referenced from:
objc-class-ref in SDL2(SDL_mfijoystick.o)
"_CHHapticEventTypeHapticContinuous", referenced from:
l002 in SDL2(SDL_mfijoystick.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Joysticks might be related to the hidapi target that SDL2 has, and perhaps I need to build it, too? How strange, and I wish the SDL2 docs said something about it.

Digging into the source for SDL2, I did find src/hidapi/README.txt which indicates that there are multiple platforms to build for, such as Mac OS X. But am I supposed to also do it for iOS? Why have I never heard of this before when it came to Linux, my main development environment? Or Android? I feel like I shouldn’t need it.

But I guess I’ll continue experimenting.

I got to spend a chunk of my personal Independence Day working working on it, and I gotta say, it was nice to be able to concentrate so much time on a hard problem at once. I doubled the amount of time I would spend on game development last week, and it feels like so much could get done with a week of such days.

What’s frustrating about not having that much time to dedicate to it regularly is that I have spent another week on trying to get things working so I can build on iOS again, and I haven’t spent time on figuring out the Android 11 issue, and what’s more I haven’t spent time on making my game itself better.

Not being able to ship a working game is a major problem, and since I’ve chosen not to use an existing game engine that presumably would have handled all of this for me, it’s on me to figure out. But it would be nice to have this working soon so I can get back to spending time on game design and implementation.

Still, I did get to show off the game to a live audience. The IGDA Des Moines chapter held its monthly meeting last Tuesday, inviting members to demo what they are working on for a few minutes and get advice from attendees. I showed off the game, and I got some great feedback.

One thing that was said that made me concerned was that “factory” in the title implies a factory-style game play. Since factory games is its own genre, there might be expectations from the title alone that the game play will match those found in Factorio or Big Pharma. I might need to find out if this is going to be a real problem requiring a name change…or maybe I just put it out there and see what the feedback is from real players.

It was also pretty cool to see what other indie game developers are working on.

Anyway, I expect that I’ll figure out this iOS build issue in the coming sprint. The main annoyance is that it seems to mean I’ll be doing MORE manual work within Xcode rather than being able to automate it through scripts and command line tools.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!