Deploying for macOS - how are we supposed to do it?

It is an utter mystery to me how we’re supposed to deploy our SDL games for macOS for other people to download and play them. On Windows it’s simple, just do a Release build and put SDL.dll along with it and that’s it.

On macOS I tried following LazyFoo’s tutorial and while the building works (though I have to change building scheme so that “Run” makes Release builds instead of Debug, and I don’t like that there’s a console popping up, or that it’s just a single binary and not a package as every other app is), once I copy the build over to another machine and try to run the game the first thing the console tells me is “dyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2” further adding “Reason: image not found” and “Abort trap: 6”. In other words it’s searching for the SDL2 framework, which it does find on my build machine because I installed it, but not on any other machine where it’s not installed.

Clearly I must be missing a very simple step that everybody else knows about, so, what is it? If you’ve ever made macOS SDL apps that people actually downloaded then you necessarily must know how to do it properly. Thanks in advance for telling me!

I’m using the pre-built SDL2 (and SDL2_ttf, SDL2_net) Frameworks and including them in the application package. That gives me a self-contained .dmg file to distribute.

So you ask the user to drag-drop those frameworks in an alias to /Library/Frameworks that you provide? I could see it work, however I have a feeling that’s not the way we’re supposed to do it.

The end-user doesn’t have to do anything other than the usual double-clicking on the .dmg to install it. The app is quite happy to access the frameworks in the package, they don’t need to be copied anywhere. You can try it for yourself:

Thanks. On High Sierra it says “You can’t open the application “” because it may be damaged or incomplete”, which I believe is a Gatekeeper/signing problem (you wouldn’t see it unless you download the app yourself). Then after opening using the context menu’s Open I get "“ is from an unidentified developer.”, also a signing issue. Apple sucks, those are problems you can’t even see unless you download your app from the web and try it on a clean system.

Other than that it works, so what’s your process for adding the frameworks? Because I tried that before inside Xcode and the app would still look for the frameworks in the system and not those copied by Xcode into the app package. And also how do you make the DMG?

It is signed, but with an Authenticode certificate, not an (expensive) Apple one!

I wrote a script. I feel it should be possible to do it in Xcode, but because my script works I haven’t investigated that.

hdiutil create AppName.dmg -volname "App Title" -srcfolder

In practice I follow that with an ‘hdiutil convert’ command to compress it, but that’s only to reduce the size a little and it’s not essential.

What’s an authenticode certificate? Apple is making it confusing with their $100/year certificate (wtf, really nickel and diming the wrong people) but I think you can sign things well enough with a free certificate (not sure, confusing and poorly explained as always with Apple). The problem happens when you put it in a .dmg, upload it to the web, then someone downloads it and only then does it tell you about anything “”“damaged”"" and how the developer is “unidentified”. And only on Sierra, High Sierra and El Capitan 10.11.5 or above.

Damn, I wrote scripts too. But this can’t possibly be the way we’re actually supposed to do it, right? Everybody is supposed to write a script that changes the path of the frameworks in the bundle? This is crazy, and might mess with the signage, I’m not sure, I’m confused about the whole problem (which is new to El Capitan so if you’re still on 10.6.8 you can’t experience what level of a mess it is), I just don’t believe that this can possibly be the way it’s actually SUPPOSED to work. I don’t use macOS much but most of the times I try downloading a macOS app you have to do a bunch of stuff. Please someone on this forum tell me you didn’t have to make your own weird script.

I think maybe what gives you the “damaged” message (seriously do try to download from the web and install it on a freshly installed Sierra or High Sierra system, you’ll see all the problems I mentioned every single time, few users actually report such problems when they do encounter them) might be the lack of signing when you make the .dmg, apparently according to these guys you need to sign your .dmg and need to be at least on 10.11.5 to do it.

I’ll have to test some things tomorrow to see if it can solve anything. Thanks for the feedback!

Authenticode is the Windows code signing mechanism, in other words I am using the same certificate to sign my Mac apps as I use to sign my Windows apps (and my Android apps for that matter). The resulting security is at least as good, but hey, we know what Apple are like!

I agree. You asked me how I did it and I told you! :slightly_smiling_face:

Yeah so Authenticode won’t help you on macOS. You should read up on the horror that is how Apple’s Gatekeeper works since 10.11.5 and how it ruins everything. It makes users jump through hoops to open anything if you don’t sign it with your AppleID certificate and now it even prevents you from accessing files in your app’s folder (outside of the app itself), which for me broke everything. And now I have a problem where I can’t figure out how to make a proper .dmg which makes my users have to launch the program from the Terminal.

So I thought “all this madness can’t be the way it’s meant to be done, I have to start over and do it the way everybody else does it”. And here we are… And Google isn’t much help, it seems like no one is explaining how to do the whole thing correctly.

It does help. The app is signed (using Apple’s own ‘codesign’ tool) and Mac OS knows that it is signed. For example the following command will give you details of my certificate:

codesign -d -vvv

It may not eliminate all the warnings, but it’s better than nothing.

Oh yeah I see, good to know! You probably just need to sign the .dmg (as they explain in the link above) with the same certificate to fix any issues for Sierra/High Sierra then.

Just a note, you don’t need a .dmg – users on macOS are fine with and expect a zipped .app, if you don’t need to install any global system components for your app to run (which most apps shouldn’t).

I’ve been offering them in ZIPs for years however with the aforementioned Sierra problems that have to do with signing I had trouble making ZIPs that work once downloaded from the web and extracted. If you have any experience dealing with that aspect of things I’d like to know how you do it!

If you want to see how it fails for me see the Sierra version from this page, I couldn’t package it in a way that works properly after it’s downloaded (only locally). As it says just once I managed to do a signed .dmg properly and then I forgot what I did and didn’t manage to do it again.

I just make a static build of the things I build snapshots for OS X (Exult, DOSBox, Nuvie, Pentagram) and am using codesign in the buildscript. Set up once and it works almost flawlessly.

I had a go at trying to upload my SDL games to the Mac Store but I think you can’t upload if you’re linking to the SDL static libraries, so I gave up in the end. If anyone has that figured out I’d love to know how it’s possible!

There must be thousands of hours of hard work put into making something like SDL but if it wasn’t for tutorials like the excellent Lazy Foo’s I personally wouldn’t have persevered with figuring SDL out. I’d have thought getting tutorials out for uploading your SDL game to the Windows, Mac, Google and App Stores would be a good idea?

Perhaps we should ask Lazy Foo if he can guide us in the processes of publishing our work, like how to properly build for release and pack everything correctly so that other people on other computers can enjoy our apps in a way that works.

Yeah, would be excellent if someone could do that but I guess it’d be a fair bit of work. I’ve just donated $100 to Lazy Foo though and I think we all should donate something for the excellent work he’s done! Unless there’s good tutorials on how to take a project all the way from start to deploying on a store then I guess SDL is just for hobbyists. I gave up with SDL on MacOS, but got it to get my games on Windows and Steam. I’m trying it on Android, but stuck at the moment so I’m thinking of doing things natively like I do with iOS at the moment. It’s frustrating that I’ve got two totally finished games for MacOS but I can’t figure out how to sell them!

The Mac App Store is well known for being derelict anyway, more developers have pulled out of it in the last couple of years than joined it because it’s not worth it. So don’t let it get in the way of distributing Mac builds, besides Steam can do that just fine and you can use your own website too (that’s what I do).

1 Like

I had a feeling there wasn’t much money to be made from the Mac Store so I wasn’t too concerned when I couldn’t figure it out, but it seems a shame not to upload your Mac SDL apps there and make even a small amount of money - better than nothing!

I had a look at the Steam Mac options but it looked way more complex than the Windows (which I’d figure out as they give us a video tutorial) so I gave up on that too. Unless I have a Lazy Foo style tutorial I give up.

I do all my SDL development on my Mac so I get finished Mac apps but I never sell them! When my games are done I copy the code over to my nasty old Windows laptop, hit build, and upload them to Steam.

I still don’t understand why you don’t distribute them yourself on your own website. It’s dead simple (you just provide a .zip or .dmg) and no one takes any money from you (except PayPal). I’d say I make about half of my money from Mac sales (although I’m in the audio business which is Mac-heavy) and this also allows me to do MacUpdate promos. I’ve never even bothered with any app store, I just distribute myself and still make a living out of it. You’re saying no to a lot of money when you don’t distribute yourself let alone sit on perfectly good Mac builds that no one is allowed to have.