The only thing left to solve is to actually build cross platform. You can do with rust cross but you have to build your own docker images on macos first since apple licensing prohibits redistribution of binaries. It would save us so much money in github CI minutes.
This is actually a solved problem, using osxcross[0]. The experience is honestly very smooth, and we don't require any apple proprietary binaries. The only thing apple-proprietary is their SDK (containing the header files for compiling, and tbd files for linking), which can be downloaded from apple's website (at least if you have a developer account), or from various GitHub projects archiving them.
That’s relatively easy to do, with the only questionable/legally gray area being access to the iOS/Mac SDKs. I’m not a lawyer, but it’s my understanding that the Google v Oracle case established that APIs aren’t protected by copyright. So if we can use the headers from e.g. the iOS SDK on Linux wtohout worrying about copyright issues (Apple developer agreements may be an issue though), it should be possible to autogenerate stub libraries for linking purposes.
With that, you can compile and link a binary for iOS or Mac on Linux.
Next, you’ll need to implement the packaging and signing portion. Packaging (generating an app bundle) is easy, but codesigning requires Apple’s codesign utility, which doesn’t work outside of Mac, even with a project like Darling (last I checked, anyways).
But if the OP does implement a working codesign alternative, then that means it should be possible to create an iOS/Mac app that can be distributed on the App Store entirely from Linux with no Xcode, virtual machines, cloud macs, etc.
The only gate left then is the Apple tax/signing certificate you need to buy for $99/year. But that might change with all of the antitrust pressure Apple is facing, including the recent EU law that would force Apple to allow competing app stores.
"I’m not a lawyer, but it’s my understanding that the Google v Oracle case established that APIs aren’t protected by copyright."
I'm no lawyer either but I have read the Supreme Court's decision in the case. It doesn't address whether APIs are protected by copyright. The Supreme Court generally makes the most limited ruling needed in order to resolve a case. In this case there were two issues at play.
-Are API's copyrightable?
-If so, was Google's use of the APIs fair use under copyright law as a jury had previously ruled?
In order to make the most limited ruling needed to decide the case the Supreme Court first addressed the fair use question with an assumption that APIs could be copyrighted. The Court decided that Google's use did fall under fair use and so the case could be decided by the fair use question alone. They therefore didn't bother to address the question of whether APIs can be copyrighted.
As it stands right now there is a U.S. Court of Appeals ruling in the Oracle case that APIs are copyrightable which until the Supreme Court does address the issue means they are as far as the courts are concerned. Fair use is a case-by-case defense and the Supreme Court's decision doesn't mean that all use of an API is fair use. This is all very much still all up in the air and any use of the headers from the iOS SDK should be concerned about copyright issues.
We achieved this for Firefox macOS builds years ago. (Greg was there for that work as well. ) You do need to have an SDK accessible, but storing one internally and using it in CI was deemed acceptable. The impact on CI build times was hard to overstate.
We were already building our own clang binaries for various reasons, so it was mostly a matter of making an SDK available and ensuring that the right compiler options were passed in (since running clang on macOS sets a bunch of defaults that you don't get even if you pass -target x86_64-apple-darwin).
