Apple developer program

[Ras]

I would advice giving Apple the finger and NOT joining Anything from them

For iOS, the store conditions are incompatible with any GPL'ed software because of the additional restrictions, i.e. being unable to install the software on as many devices as the user likes. This hits GPLv2 and GPLv3 alike. Apple will take down GPL applications from the store if an author of these applications complains, as seen e.g. in VLC (see https://www.fsf.org/blogs/licensing/vlc-enforcement) and Gnu Go (see https://www.fsf.org/news/2010-05-app-store-compliance). Stockfish only stays in because the Stockfish team doesn't seem to mind violating that part of the GPL as long as the source stays open.

macOS has no such restrictions, but cross-compiling from non-Macs is a PITA because Apple's idea of building SW for Macs is that you buy one of their overpriced machines. There are repos with Xcode stuff out there, but they're of dubious legality status (hence no link here). Using them and distributing engine binaries generated with them would prove that you infringed Apple's copyright on their tools.

My solution is not to offer Mac binaries, but include a shell script for Mac so that users can easily compile from source, provided that they have Clang installed. That works both for x86 Macs and Apple Silicon.

Similarly, I don't offer Linux binaries although I'm on Linux myself, but avoiding compatibility issues as well having optimum performance both favour compiling right on the user's target machine.

[jdart]

[...]
However it is not completely clear to me from the agreement that GPL would be excluded.
[...]

Question, if you compile and sign your GPL source code with Apple magic stuff, is the compiled binary still under GPL, according to above mentioned terms, including the Apple magic in binary?

It is an interesting question. GPL v3 does say:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

So that would seem to rule out the use of a proprietary installer, or one that had proprietary components.

[wickedpotus]

I am not all that fond of Gatekeeper either, but the other side of it is that there is a lot of malware out there, including malware that tries to disguise itself as a legitimate download. So that is one reason Apple and Google have an approval process for apps (even though it is not completely effective at preventing unauthorized ones from installation).

This gatekeeper "security by obscurity" approach most likely does more harm than good. Consumers get a false sense of security (if a device is hacked u never even see it because u lack auth to look behind the "facade". Not even allowed to take ANY counter-measures controlled by yourself, 3rd parties or anyone other than the gatekeeper. We've seen all hacks, 0-days, and companies like Pegasus, NSA/Dropouttjeep giving anyone with enough money access to compromise the security of ANY user easily trough the "gatekeepers" software distribution with lack of transparency. This is just BAD!
Openess > obsurity and gatekeeper model currenlty applied by un-open companies like Apple.