If I understood it correctly “Apple Silicon (M1) p...

# compose-desktop

[Michael Paus]

If I understood it correctly “Apple Silicon (M1) powered macOS runners” are now available on GitHub. So we can finally build Compose desktop apps for ARM Macs directly on GitHub.
https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/

[Carter]

Apple’s build toolchain should always have allowed building ARM binaries from an Intel Mac and vice versa.

[Michael Paus]

Then tell me how to build an M1 compose desktop app on an Intel mac. As far as I know the tooling provided by JetBrains does not support that.

[Arkadii Ivanov]

This looks like an issue with tooling? Of course it's good to have arm macos runners, but is there a ticket for Compose for Desktop?

[Michael Paus]

A ticket for what exactly? At the moment an app with Compose for Desktop can only be built on the platform you are targeting. That’s basically a limitation of the Java tooling used and as such is by design. Of course it would be nice to be able to cross-build for other platforms too (and sub-platforms like ARM and Intel Macs) but that would rather be a feature request than an issue. At first jpackage would have to be enhanced to allow cross-builds.

[Arkadii Ivanov]

What I mean is that there is no limitation from the Apple/macOS side, as far as I understand. E.g. I've been publishing all targets of a normal KMP library from just one single macOS x64 runner - the KMP plugin produces binaries for all architectures and all targets. So if I would be interested in building Compose for Desktop apps for macOS, I would file a feature request for the relevant tooling team.

[Arkadii Ivanov]

It could be also useful to build universal apps, that are able to run on any architecture.

[ephemient]

it's not a problem with JB's tooling directly, but Java's own jpackage only works for the current architecture as in bundles the current JVM

[Sebastian Kürten]

what's interesting is that jlink is actually capable of building runtimes cross-platform from module directories for a JDK's module for other platforms. Additionally, as @Arkadii Ivanov mentioned you can build the binaries of an app cross-platform (usually that's just a jar file with platform-independent class files) and you can download dependencies for all platforms such as the platform-specific skiko library on any platform. So all the tools exist to build executable apps cross-platform that include a native, customized runtime and all libraries needed to run your app (see also @jw’s article here https://jakewharton.com/using-jlink-to-cross-compile-minimal-jres/). One thing that cannot be done cross-platform with the JDK's tools is creating the launcher executables that are needed for the user to run your app that's usually built using jpackage. It is however surprisingly easy to mimic the behavior of jpackage when it comes to that. Basically it just copies over a pre-compiled, platform-specific executable that's shipped with the JDK you're using as a blueprint to build your app from. That executable doesn't need to be modified or recompiled, it can instead be configured using an accompanying *.cfg text configuration file that basically defines the main class to run, the libraries to put on the classpath etc.

[Arkadii Ivanov]

If the problem is with jpackage, can we file a feature request for them? Do they have an issue tracker or something? I'm just not familiar, sorry.

[Sebastian Kürten]

I don't think it'll fall on fruitful ground. The JEP (https://openjdk.org/jeps/343#Non-Goals) states this as a non-goal: "There will be no support for cross compilation. For example, in order to create Windows packages one must run the tool on Windows. The packaging tool will depend upon platform-specific tools."

[Arkadii Ivanov]

This also applies for different architectures of the same platform?

[Sebastian Kürten]

I think it does and it makes sense. Allowing the JDK tooling to work cross-platform adds some significant complexity. Instead of being able to just run it locally (the JDK has all that it needs locally to build a runtime + app for the current platform + architecture), it would need to be aware of a mechanism to retrieve a JDK for a different platform/architecture.

[Arkadii Ivanov]

Thanks for explaining!

[Sebastian Kürten]

@Michael Paus one thing I'm wondering is: will M1 runners replace x86 runners entirely? Or will it still be possible to run classic macOS pipelines? If not, it'll be possible to build M1 apps going forward but no longer to build for Intel-based macs.

I don't see any mentioning of an architecture selector in neither https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners nor https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/

[Michael Paus]

@Sebastian Kürten Of course I can’t say what GitHub is planning for the future but at the moment you can distinguish between Intel and ARM indirectly via the macos-latest-xlarge vs. macos-latest-large runs-on: key. So it looks like this double-architecture feature might go away some time.

[Sebastian Kürten]

ah, OK. I also found this now https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners which at least mentions the architecture for the different large runners on macOS explicitly.

[Michael Paus]

@Arkadii Ivanov I haven’t yet filed a request to enhance jpackage (although I even have JDK author status) because previous attempts in that direction where just rejected. See, e.g., https://bugs.openjdk.org/browse/JDK-8313740 I even think that handling the specific situation of different architectures on the same platform would be quite easily solvable. Jpackage does not need the functionality to download anything itself because the user can just download a second JDK for the relevant architecture and can point jpackage to that via a command line argument. Once you have that option everything else should already be in place.

[Sebastian Kürten]

Good point that the user can provide the JDK for the other architecture! Also interesting to read about the ideas and attempts to build universal apps that run on both mac architectures. Looks even like somebody succeeded already in building universal JREs and then universal apps on top: https://incenp.org/notes/2023/universal-java-app-on-macos.html

[Sebastian Kürten]

Not sure why the author is using their own custom compiled launcher though instead of just combining the two launcher templates that come with the two JDKs and combines them to a single launcher using lipo as with the rest of the JDK.

[Michael Paus]

I am personally not a big fan of universal apps because they are huge and more difficult to create with the Java toolchains. At the moment I deliver only Intel versions of my desktop app because up to now I wasn’t able to build for ARM and because these Compose Intel apps run very nicely on ARM macs too via Rosetta 2. This is almost transparent to the user and the performance is reportedly very good. So the pressure is not so high at the moment and I am also planning to buy a new Mac anyway.

[mikehearn]

N.B. Conveyor has been able to do this from the start. It's not an issue with Apple's toolchain indeed, it's a jpackage limitation. You have to do cross builds, or use Conveyor.

[Michael Paus]

Conveyor is still on my to-do list but I first have to clean up some other issues 😉.