What's so hard about porting to a new hardware arch? Why would building for ARM Macs be any different than x86? Unless you have assembly code it's just a matter of changing a compiler flag, isn't it?
A couple of issues that came up for me when porting from x86 to ARM recently:
1. The x86 architecture gives programmers a lot of memory ordering guarantees, so that communication of values between threads does not usually need memory fences. ARM64 does not give so many guarantees, meaning that multi-threaded code may need additional memory fences to avoid data races. But data races due to out-of-order memory updates are hard to diagnose.
2. Page size in macOS is 4 kB on x86, but 16 kB on ARM, so if someone has hard-coded the page size rather than calling sysconf(_SC_PAGESIZE) this may need to be discovered and fixed.
Aside from the points in the other comment, it takes time to change the build/test/release process for a new architecture. In some codebases it's a matter of adding a line to a Makefile, in others it's writing hundreds of lines of Bazel and a new CI pipeline.
Getting a Silicon build of Gimp wasn't actually that difficult. I know at least one other person besides myself that had gotten a build working from source and published how to do it in some form. The problem is that the CI system Gimp used for the Mac build did not have ARM runners, yet. This meant that to produce the production build required cross-compiling from an Intel Mac. While I'm sure it's possible to accomplish this, it was quite tedious and I gave up. As an example, one problem was that the Gimp build process builds tools that need to be run on the system doing the build and just splitting out those parts from the parts that need to be compiled for the target system was tedious.
A recent change in Ardour that used int128_t did not break on ARM nor did it break on unoptimized x86_64 builds, but did break on optimized x86_64 builds. That's just one example of the sort of platform-specific madness that may need to be faced and chased down.
Just providing a link to stackoverflow discussion that seems to relate to this, as I was curious about the details. Looks like it was undefined behavior relating to casting pointers.
What is true is that if you want users to be able to just download and run (rather than download, run an obscure command, and then run your software), you have to pay Apple to notarize your builds.
> rather than download, run an obscure command, and then run your software
This also isn't true.
On a Mac (or on Windows) software that has not been digitally signed will show a scary dialog box telling you that software you download off the internet might be malicious.
On the Mac, to bypass this, you just right click the software and pick "Open".
1. The x86 architecture gives programmers a lot of memory ordering guarantees, so that communication of values between threads does not usually need memory fences. ARM64 does not give so many guarantees, meaning that multi-threaded code may need additional memory fences to avoid data races. But data races due to out-of-order memory updates are hard to diagnose.
2. Page size in macOS is 4 kB on x86, but 16 kB on ARM, so if someone has hard-coded the page size rather than calling sysconf(_SC_PAGESIZE) this may need to be discovered and fixed.