Add darwin arm64 target

[squash]

Go 1.16 was released today with support for the new MacOS platform, darwin/arm64.

[Jacalz]

I think this might take a little time to get working. Firstly Fyne itself needs to support compiling in the Apple M1, see fyne-io/fyne#1739. There is a PR open that fixes it but it is not done and might require more thought to make sure that compiling for iOS still is compatible with older Go releases.

Then there is the issue with the licensing for the Apple SDK. I think it might require a new version and we cannot quite distribute that.

It will also of course require an update to Go 1.16 which has a couple points to consider before doing so. We are still on Go 1.14 as Go 1.15 drops support for one more MacOS release. The SDK that we are using is for the version that is being dropped and I don’t know if it will compile with newer Go versions. That requires testing, but assuming that it does work, upgrading should only be a matter of the team being okay with a MacOS version being dropped (as Go 1.16 does not drop any more versions).

I have perhaps painted a bit of a dark picture here, but it should all be solvable one way or another. It just requires some clever thinking and agreement with the team 🙂 We might end up having the user download the Apple SDK manually on to their computer (due to distribution issues with licensing).

I am curious as to what @lucor has to say about it. At the end of the day, he is the main developer and professional when it comes to fyne-cross 🙂

[Jacalz]

I might also want to specify that I am personally very interested in this per Jacalz/rymdport#7.

[squash]

Just as a bump, fyne-io/fyne#1739 was closed today with a fix in the develop branch.

[Jacalz]

I'll be spinning up a test image using Go 1.16 later today for some testing (just the Go update, not any arm64 support). Will update here with any developments.

[Jacalz]

Looks like darwin builds indeed can't compile with an updated Go version. I think we need to figure out something better.

cc @lucor

[andydotxyz]

Did I misunderstand this message, or is it true that Go 1.16 does not work for darwin?

[Jacalz]

Did I misunderstand this message, or is it true that Go 1.16 does not work for darwin?

That's correct. Our macOS SDK is for 10.11 and later but Go 1.15 only support 10.12 and later, thus it cannot compile for Darwin on amd64. We'd need to update the SDK.

[Jacalz]

I can double check Go 1.15 tomorrow to make sure that it wasn't a bug in Go 1.16.

[andydotxyz]

It works perfectly well with Go 1.15.
The macOS SDK is part of fyne package not part of the go compiler, so upgrading Go should not have changed anything.

My current build platform (compiles and packages correctly):

❯ go version
go version go1.15.7 darwin/amd64

[Jacalz]

I’m not saying that Go 1.15 doesn’t work on MacOS, I am saying that it doesn’t work with the SDK that we have in the fyne-cross docker image. That SDK is for 10.11 and I could not get fyne-cross to build using Go 1.16. As it was an error about linking to C-code I assumed that it was due to 10.11 no longer being supported as of Go 1.15 and later. Will check Go 1.15 in fyne-cross tomorrow and see if I find the same error happening there as well.

[andydotxyz]

Aaah! That all makes sense :)

[lucor]

@Jacalz has reported all the issues regarding this activity, so no more to add there. I'd try just to recap the action items in order to figure out a possible way to get this sorted...

• darwin arm64 support in fyne: landed in develop with Error compiling fyne on Apple M1 arm64 fyne#1739
• update fyne-cross to use Error compiling fyne on Apple M1 arm64 fyne#1739
• add the arm64 arch to the supported arch for darwin in fyne-cross
• update the base docker image to go v1.16
• update to the latest macOS SDK version supported by go v1.16

As reported above the major issue is with the last point due to the SDK licensing that does not allow to redistribuite the SDK into a docker image.

As discussed previously into the slack channel, one possible to solution is to have the final user to build itself a local copy of the macOS docker image.

First ideal comes in mind is to have a fyne-cross command that given a valid Apple developer account will download the SDK and build the docker image.

Since handling the auth on the Apple dev site could require some effort, probably as first step a command (or a bash script / make task) that builds the image using a local copy of the SDK already download by the user could be good enough :-)

[Jacalz]

@lucor Would it be possible to load the SDK from the computer at runtime without having to recompile the docker images? Compiling the images a takes a lot of time and it would be great if it could be avoided.

[lucor]

@Jacalz we could try something like that, but the great part of the time is spent to create the osx toolchain starting from the xcode package :(
Further details can be found at the osxcross project (the tool used to create the macOS Cross toolchain for Linux and *BSD) but basically the steps needed and that takes time are:

• download xcode (~11Gb)
• extract the macOS SDK
• install dependencies required by osxcross
• build OSXCross toolchain

Some time could be saved providing a base image with the desired version of Go and the required dependencies but IMO it will save only a small fraction of the total time...

I do not like the build all locally way too, especially for users that does not have a fast internet connection... but unless it is not possible to host the image or rely on a third-party one no other solutions comes in mind.

[lucor]

The PR #34 add support for darwin arm64 along with some other new stuff like Go v1.16.
Help with testing on that architecture is welcome :-)

[shawnbutts]

ideally, the darwin arm64 support would lead right into darwin universal. "native" apple apps don't require the user to have knowledge of which processor architecture they are on.

[Jacalz]

ideally, the darwin arm64 support would lead right into darwin universal. "native" apple apps don't require the user to have knowledge of which processor architecture they are on.

I’m not so sure about that. We are using a compiled language. If we want universal apps, we should just use interpreted languages like Python. Either way, I don’t think it’s anything that we can do anything about unless Go supports it.

[andydotxyz]

@shawnbutts Yes, darwin apps (like our iOS apps) should be universal.
I don't know if this needs any additional support from Go to make this work - either way it is a separate issue from this one.

[andydotxyz]

If we want universal apps, we should just use interpreted languages like Python.

Sorry but I disagree with this @Jacalz we can, and should, continue to make it easy for users to manager their apps without technical knowledge. Universal apps may be part of this. It's just a case of compiling in multiple architectures to a package - a solved problem.

[Jacalz]

I wasn’t talking about iOS apps running on M1, that is something that I think would be the future. I just meant general Go binaries that run on amd64 and arm64 (straight out of go build). That is something that I don’t see happening. Partly due to making binary sizes massive and partly due to Go dropping support for one macOS version each year (thus Go 1.22 being the last to support Darwin amd64, assuming that they don’t want to keep it). Either way, that’s probably a discussion for another time 🙂

[andydotxyz]

I wasn’t talking about iOS apps running on M1

I understood this (as iOS running on M1 is something Apple supports rather than the compiler). I was merely using iOS as a comparison, as our iOS apps (and Android) (can) support multiple architectures.

[andydotxyz]

thus Go 1.22 being the last to support Darwin arm64

Do you mean amd64 here? I doubt very much that Apple will remove amd support so fast - it will be many years in the transition, and there will be some years of support after the old machines are no longer built.

[lucor]

Having the possibility to create also a universal binary would be a nice to have.
We could expose it as an additional target, leaving at the end user the target choice: amd64, arm64 or universal.
Anyway as @andydotxyz said above, this requires further investigation and it is a separate issue from this one.

[lucor]

cross-compiling for darwin arm64 target is now available for testing in develop (#39)