Fixing the SFML Template in Xcode 12-ish

When I was trying to learn Unreal, I wanted to learn more C++ so I would feel comfortable working with the scripting. The book I was working through used the SFML library for building games. I was going to try to set this up in Visual Studio Code, but the SFML website recommends using Xcode. They even have a template and a tutorial about how to install it on the Mac.

I had some concerns about the template as the website says it will work in versions of Xcode above 4 and we just got version 13 a few days ago. (I didn’t update yet and had to look it up quick.) I thought it might need some work, so I tried to build the project directly after creating it and got a bunch of linker errors and other shenanigans.

I went to my husband (who has way more experience in this area than I do) and he spent like ten minutes fixing all the stuff that was wrong. (Side note: I am unsure if I would have figured this out on my own. I don’t know a lot of people who would have because most of the programming community has experience with high level abstractions that are maintained by people like my husband. Low level experience is hard to find!!)

I don’t think there is a massive glut of people who are chomping at the bit to do SFML or C++ development on the Mac, but if anyone is curious, here is a list of the changes I had to make to get the template to build in Xcode 12.ish.

Move the info.plist and Create a Resources Directory

Once you create a project using the SFML App template (which creates and entire application bundle and not just a binary), the first thing you will notice is that there are a bunch of disconnected resources in the resource navigator:

Screen shot of the file navigator with disconnected resources.
File Navigator with disconnected resources

This is one of the more simple problems to solve.

  • Move the info.plist from the Supporting Files group and place it directly into your main directory.
  • Delete the Supporting Files Group
  • Right click on the project in the resource navigator and choose “Show in Finder” to reveal the directory in your file system.
File directory with the incorrect configuration
File directory with the incorrect configuration
  • Create a “Resources” folder inside the directory
  • Move the four disconnected resources into this directory
File Directory with the correct configuration
File Directory with the correct configuration
  1. Go back to Xcode and use the file inspector to change the resource path for each asset.
Incorrect file path
Incorrect file path
Correct file path
Correct file path
  1. Restart Xcode. It won’t really “take” the resource path change until Xcode reboots.
Final version of the project navigator
Final version of the project navigator

To be fair, the only really “necessary” part of this process was to move the info.plist. If you deleted all the code in the main.cpp function, you would not need these assets and could simply delete them. But I like to get the project to a known good state and just wanted it to build as expected.

So this was the easiest fix. Next up is digging around in the build phases.

Build Phases

This section has to do with a discrepancy in how you are told to install the framework versus how the template assumes you have installed the framework.

First, navigate to the build phases in your template application and expose the Run Script:

Build phase run script that is incorrect
Build phase run script that is incorrect


The script is set up to look for your SFML header files and libraries in the file path “/Users/SFML/Desktop/packaging/tmp/install/Library/Frameworks”. But if you follow the directions used by the SFML documentation, the file path for your frameworks should be “/Library/Frameworks”.

My preference is to keep all my frameworks where they are supposed to be instead of creating a temporary folder on my desktop, so I change the first three settings to reflect the actual file path.



Corrected run script
Corrected run script

”Provisioning” and Code Signing

Alright, I am aware that Apple has been pushing people to build universal apps that work on both the Mac and the iPhone. I have been fairly open about the fact that I have not been keeping up with everything going on the past few years, so I don’t know if things are different for provisioning. When I was still an Apple developer, I only did provisioning for iOS as that was the only job I had for most of my career.

My understanding is that the rules have relaxed somewhat when it comes to having profiles for just building to your own devices. At some point I will document getting an actual provisioning profile for the Mac when I have something I want to ship, but you have to have something in place in order to build on your machine and this is my shortcut.

  1. Go to your Targets->Build Settings-> All -> Levels -> Code Signing Identity.
How to find the code signing identity
  1. Select “Other” from the drop down menu.
I am fairly certain we tried the “Sign to Run Locally” option and it didn’t work and we didn’t debug it. I don’t think we were that stupid to not try it. /Snark
  1. Delete everything in the script
Empty code signing probably won’t get you through the App Store approval process, but at this point what will?

This is absolutely not a best practices thing. This is a total hack. This is my “I want to practice writing C++ code on my Mac and I want to see if it builds or not” hack. I will eventually have to figure out code signing and other bullshit if I want to ship anything I write here, but for my own narrow purposes, building is sufficient. If you already have this set up properly or I am doing something completely idiotic, feel free to ignore this or mock me.

Keyboard Input in Catalina

At this point your template project should build. Mazel Tov. However, if you want to run it you have one last bit you need to do.

In Mac OS Catalina, there were some changes to the permissions for allowing other applications to receive input from the keyboard while other applications were running.

The first time you run an SFML app, you will be prompted to give the application permission to use the keyboard while it is running concurrently with other applications. When I did this, I was dumb and made my game take up my entire screen, so I didn’t see the prompt. So even though I was clever and added keyboard monitoring to quit the program if I tapped “Escape,” I didn’t get the prompt to enable it, so the application had to be forced quit. D’oh!

So make sure to either enable this in the Security & Privacy settings or make sure your game is smaller than your screen so you get the prompt to do so without digging around in the settings.

I blocked out my “secret” project I am probably going to write about next week.


I am aware that I should probably put in a pull request to implement these changes on the actual template that is accessed by developers, but I don’t really understand the process of updating a template. I grok some amount of how to update a code base, but this is slightly outside my area of expertise. The Husband has some experience with maintaining open source projects, so some day when we both have a spare spoon he is going to help me put in the pull request. So it will probably happen after The Singularity.

The Engines of Creation

One of the biggest roadblocks I have encounter while trying to learn game development is dealing with an engine. My background is in iOS development and Xcode is sort of a happy medium between an IDE and an engine.

I didn’t quite understand a lot of how all the pieces worked together and talking to people whose only context about development was from games didn’t help much because people just didn’t have a mental picture of doing things any differently.

So, after several years of exploring various engines, my decision at this point is that I don’t want to use any of them.

Here are my reasons for not wanting to use the ones I am most familiar with:

  • Unity: Oh god, where to begin. I started with Unity and tried to learn it over the course of several years and I just don’t like it. I don’t like the user interface. I don’t like the gray box level builder. I don’t like their code frameworks. I don’t like C#. I additionally do not like that they keep adding multiple ways to accomplish something and then stop supporting them, leaving developers to hope they picked the right way and it will keep working moving forward. I talked to a bunch of indies who have used Unity for a decade and none of them thought any of this stuff was an issue. It was simply the way things are and you get used to them. I didn’t want to get used to it and wanted to find a better way.
  • Game Maker Studio: I want to start with 2D because my art skills are not great yet, so GMS was an option. It seems somewhat easy to learn and use, but it utilizes a proprietary scripting language and it charges you money for its use. Neither of these is ideal. Also, one reason I was interested in GMS was because I read Spelunky was created in it. After reading Derek Yu’s book about Spelunky, I found that he prototyped it in GMS and then actually built the version I play with in a custom engine. So this doesn’t seem like a good long term option.
  • Unreal: I will be honest, of all the engines I tried, Unreal was my favorite. I liked the frameworks. The shader builder was slick. The interface was nice to use. It actually works because the people who built it use it to ship games and things don’t just fall into ruin. It also open sourced its code so you can look at how things work and put in fixes if necessary. My only real issue with Unreal was that it is designed around larger teams doing 3D shooter games. A lot of the code is abstracted away to facilitate teams with a bunch of non-coders. In order to set up a 2D game I would have to position all the elements in 3D space and set up a camera. I really don’t want to do that. I loved learning Unreal while I was working with code, but once I had to work with the gray box environment, my brain would just black out. I’m sure there are ways around using the gray box, but I am too frustrated to deal with them right now, so I am considering revisiting Unreal once I have more experience building things.
  • Godot: I was under the impression that I had to use a language I do not know for this, so I didn’t seriously explore it. I will revisit in a few years as it seems to be changing and advancing quite rapidly.

While I was trying to learn Unreal, I realized I don’t feel comfortable with C++ code and syntax, so I decided to actually take a deep dive into the language. Everyone was warning me away from it because “It’s terrible!” But I didn’t actually find it to be so. I know the warnings are from people trying to debug code other people wrote that is in production and so forth, but I found the actual language to be well designed and similar to languages I already know and like. I am sure I will grow to hate it as others do, but for today I have found it surprisingly pleasant to work with.

I worked through a book on C++ game development that used the Simple Fast Media Library (SFML) to place sprites and do rendering. This library also felt very intuitive to work with. I found working with this language and this library to be the most intuitive way for me to work on games. So this is the combination I will utilize for at least the next year.

SFML also has a template that can be applied to Xcode to allow me to use Xcode for SFML development. I spoke with one of the maintainers on Twitter who indicated that I can build code I wrote in SFML to desktop and mobile devices. At this point I don’t need to ship to a console, so this is sufficient for my needs.

I don’t know if this counts as building my own engine or not. I’m trying to avoid touching low level rendering as that is a rabbit hole. SFML wraps OpenGL so I don’t have to get that working to build games, so there is just the right amount of abstraction for me right now.

A lot of the past couple of years has been me trying to force myself to learn stuff that doesn’t go with how my brain works. I logically understand that using an engine gets you a lot of advantages. But most of the big ones are not designed for people like me. For better or worse, I think in code. I have never been good at thinking about things in 3D spaces and I really do not like how the engines are designed around building visuals in these spaces and attaching scripts to them. I understand if you are building Fortnite that this functionality is vital, but it’s not if you’re building Candy Crush.

When you are learning a new skill, it can be overwhelming because there are fifty things you don’t understand. Knowledge comes from slowly learning bits and pieces of these things and winnowing them down until you don’t understand a third of them. Then you stop noticing the things you didn’t know before and can focus on the few things you still need to understand.

My hope is to spent the rest of this year and all of next year building small games. I would like to “ship” them by uploading them to something like and selling them for a buck. I hope that after I have done this three or so times, I can come back to something like Unreal and feel more comfortable with the interface as I won’t have to learn the language and how to build a game.

If you are struggling to learn something you really want to understand, it’s okay to think about why you are struggling. Is it the tools? At what point do you just give up on something even though you don’t want to? Is there a way around the thing you don’t want to do? Not everyone thinks the same way and it is totally okay to pursuit a different direction if what you are currently doing isn’t working.