That wouldn’t be too much of an issue if you could just cross compile like you can with go. However graalvm can’t do this yet.
In nutshell I don't see how having Apple Silicon locally makes the problem - if your non local env (dev, prod, stage) is running on x86 Linux or even arm Linux, shouldn't be any issue to build for that architectures on your build farms anyway.
I may be missing some important part here.
Putting on my tin-foil hat for a sec: GitHub is owned by Microsoft, who would really stand to benefit from slowing down Apple Silicon adoption a bit...
The rest of us is still running on racks of Mac Minis
https://devblogs.microsoft.com/devops/cloud-hosted-mac-agent...
> Please be aware that during this preview, our Mac hardware is hosted in third party datacenters in the United States and your build and release data could cross geopolitical lines. After each build completes, its macOS VM is reimaged, leaving no trace of your data on the agent. For more information, see where VSTS data is stored. Our Mac datacenters will expand to other geographies soon
>Agents that run macOS images are provisioned on Mac pros with a 3 core CPU, 14 GB of RAM, and 14 GB of SSD disk space. These agents always run in the US irrespective of the location of your Azure DevOps organization.
And Apple's EULA makes them basically unusable as short term rented servers, there's a minimum of 24h which is ridiculous.
But a lot of projects have tests they want to run on their target platforms.
If you build your Linux release on Windows, you might accidentally release a .zip where your binaries aren't executable. If you set up cross-compiling to Mac 5 years ago and tested it then, perhaps in the meantime code signing has become mandatory. If you build and test on Linux and release to Windows, perhaps you'll get tripped up by filenames becoming case-insensitive.
Some projects are keen on testing on all target platforms to flush out issues like that.
”(ii) each lease period must be for a minimum period of twenty-four (24) consecutive hours;
(iii) during the lease period, the End User Lessee must have sole and exclusive use and control of the Apple Software and the Apple-branded hardware ”
https://www.apple.com/legal/sla/docs/macOSMonterey.pdf (Section 3.)
My solution was to give up using my M1 mac for development work. It sits on a desk as my email and music machine, and I moved all my dev work to an x86 Linux laptop. I'll probably drift back to my mac if the tools I need start to properly support Apple Silicon without hacky workarounds, but until GitHub actions supports it and people start doing official releases through that mechanism, I'm kinda stuck.
It is interesting how much impact GitHub has had by not having Apple Silicon support. Just look at the ticket for this issue to see the surprisingly long list of projects that are affected. (See: https://github.com/actions/virtual-environments/issues/2187)