How do apps work on a Mac?

[Nash]

Say I have a standalone IPK3, and imagine I have self-compiled a homebrew fork of GZDoom. To my understanding, this produces a single file that contains the entire app... that's how apps on Macs work, right?

Anyway, then let's say I'd like to include a separate launcher app. It's a simple GUI that simply executes an external executable (in this case, GZDom). Something like this:



Now, assume that this launcher program (the one I'm showing in the screenshot) is also a standalone app that runs by itself on the Mac. How would I distribute this with my GZDoom-based game?

For example, on Windows, I can just package it like this:



But would this setup work on a Mac? I know I can just zip both the custom GZDoom app and the launcher app in the same ZIP file, but to my understanding, the user then has to then drag both apps into their "Applications" bar (and Mac OS will ask if they'd like to install the apps if they are unverified and downloaded off the internet; this I am aware of)... but how would MyGameLauncher actually find the custom GZDoom app?

On Windows, this is easy, the launcher is just hardcoded to look for MyGame.exe relatively. But I have no idea how this would work on a Mac.

Doesn't help that I only have a 2008 Macbook that can't even run GZDoom so I can't even do my own experimentation... >_<

Any help would be much appreciated.

[_mental_]

GZDoom is distributed in form of application bundle. It's just a folder with a particular structure.
Bundle may contain severak executable files along with their resources. The default executable is defined inside Info.plist.
One executable file can launch other executable like on other platforms.

---

Code: Select all

GZDoom.app
+- Contents/
   +- MacOS/
      +- fm_banks/
         +- GENMIDI.GS.wopl
         +- gs-by-papiezak-and-sneakernets.wopn
      +- soundfonts/
         +- gzdoom.sf2
      +- brightmaps.pk3
      +- game_support.pk3
      +- game_widescreen_gfx.pk3
      +- gzdoom                             <-- executable
      +- gzdoom.pk3
      +- libMoltenVK.dylib
      +- lights.pk3
   +- Resources/
      +- zdoom.icns                         <-- icon
+- Info.plist                               <-- defines default executable

You need a Mac that runs 10.9 or newer in order to experiment with this.

[Nash]

Understood. That's very helpful and exactly the kind of answer I was hoping to read.

Now, I'm already browsing second hand/refurbished Macs on my local shopping website. :) I literally cannot afford brand new Macs so these refurbished units will have to do for now.

Is this any good? The GPU looks trash of course but I'm wondering if this is enough for homebrew GZDoom? I'm just interested in compiling and doing mod testing.

[dpJudas]

Buying that thing will be the equivalent of getting a Windows 7 PC for compiling and testing for Windows 10 and 11.

[_mental_]

It's enough to run GZDoom with exception of Vulkan renderer. Compiling it is a completely different story.

In theory, Xcode 8.2.1 should be able to build GZDoom. However, after the recent switch to C++17, this might be no longer possible.
This also depends on the way you want to handle dependencies. For instance, MoltenVK needs much newer Xcode, 11+ at the moment.
Building a universal binary, Intel and ARM architectures combined, is out of question thanks to Xcode 12+ requirement for ARM64 target.

In general, testing prebuilt GZDoom is pretty straightforward. There are lots of things to consider if some development is planned though.

[dpJudas]

My advice would be to either simply accept it isn't worth the hassle as an indie developer to grab the last 10% market share, or get a Mac Mini. They aren't too expensive to begin with. Anything pre-M1 is pretty much obsolete and you will not be able to use it for testing for very long beyond confirming something compiles.

[Graf Zahl]

x86 Macs won't disappear that quickly. People still use MacBooks from 2013 these days so the remaining shelf life of the platform will be several years. Not even Apple can afford to piss off their users like that.

The bigger problem here is where Macs are normally used. It's not for gaming but for doing work mostly. The last GZDoom survey had Mac users at roughly 2.9%, which is less than Linux and a lot less than Apple's actual market share. Steam confirms the same trend, btw.

On the other hand, you need a developer account with Apple to be able to sign your stuff for distribution and constantly be on alert to meet their ever-changing requirements. I don't think it is a coincidence that there's so little free software avaialble on the platform, and you got to pay even for the most mundane stuff, where you have the choice of 10 free options on Windows or Linux.

[Nash]

Alright. Yeah, seemed like an uphill and losing battle even before I made this thread.

[Rachael]

To be quite honest I think about the only thing holding the Mac platform afloat is Adobe. There is the whole brand loyalty aspect of course, and the whole not wanting to learn new things thing, but the thing that's keeping Apple in business are iPhones, not Mac computers. And Apple knows it, too, hence the whole locking down the platform thing, as well.

[Graf Zahl]

IMO the main thing keeping Macs afloat is XCode. You need a Mac to develop Apple software, and Apple mercilessly uses it to extort inflated prices from their customers.

[dpJudas]

I've actually been pretty happy about my Macbook Pro (2015) that I had for many years. The OS always served me well (aside from a few moronic things like how you cmd-tab or what the home/end buttons do). It sure beats my Dell XPS 15 - my god that's a crappy laptop. Never buying Dell again that's for sure.

The only thing that doesn't make me want to buy an Apple product is funny enough Apple. The way they treat me as a customer, software developer and owner of my hardware has forced me to stay away from the platform, sadly.

[Graf Zahl]

Yeah, that's the big problem. Which is the reason why the things that help keep the platform afloat are mainly lock-in related.

[Dancso]

I've been there.
Worked on a small game for a publisher, they had a big mac fanbase (boomers), so it was required to deliver to mac.
Me being a windows user, I was constantly in an uphill battle with issues mac users would run into (not knowing how to right click, tons of little technical issues etc)
I ported the game from an outdated Java engine over to Unity, which helped a bunch on the technical issue front. But I figured I'll pick up a used mac mini just to test every new update for good measure.

Late last year I start getting reports about the game not launching. I look into it and it turns out to be some kind of a... execution permission issue? I look at the permissions for the bundle, it looks like it's supposed to work but doesn't.
I hit a dead end, some months go by, suddenly users tell me it works now, and they are thankful for the fix. I ain't do nothing. My best guess is, some OS update changed behavior.

This is not some kind of stab at Mac by the way.

Long story short, i did not get a return on my investment. I feel the hours I spent fixing for the platform would've been better spent on the one I already knew well.
I guess my point is, you may need strong dedication or a lot of resources to cater to alternative platforms. Even some larger studios don't find it worthwhile.

[Nash]

That's exactly the kind of input I need - thank you Dancso. I know where my priorities should go to, now... :P

[Rachael]

Well with Linux, at the very least the GUI functions very similarly to Windows, in terms of shortcut keys and the way the mouse behaves. When you pick up one you already understand the other pretty well, even if you have trouble grasping the underlying system for the other one. Problems that occur on Linux that are unique versus Windows always occur in the backend, or at the core of the program, and rarely is the problem directly on the program's interface or upper level code.

So that does make it feasible to provide cross-platform support, at least with Linux.

With Mac, it completely changes the game. Ctrl keys are now Cmd keys, you Cmd-tab to window switch instead of Alt-tab, windows no longer have their own menu bar, they use a shared menu bar that appears at the top of the screen for all applications, and closing an application's windows no longer actually exits the application, it is still running in the background unless you remember to explicitly File->Quit the application. Let's not forget the arbitrary window controls being on the left side versus the right side for the opposite system. (At least Mac was kind enough to color code their's - that does make it easier)

Unfortunately it's hard to say who was the divergent here - Microsoft or Apple. But Windows is older than Macintosh is, even though it did play catch up with a lot of Mac's features as the two evolved over time. Either way though - each of the two platforms stuck to their own rules, stealing only useful features from each other, and refusing to come together on a standard for how a computer interface should operate. So we're stuck with two systems that are so completely similar to one another yet so completely different - different enough - and with a high enough barrier for entry - that, honestly, I kind of wish Mac didn't exist, so that I wouldn't even have to worry about it.