Kind of neat how well #GNOME apps fit in on macOS :) Since @nila added support for macOS to #puregotk in https://codeberg.org/puregotk/puregotk/pulls/43 this week I thought I’d give it a shot on my new MacBook Neo - and it works really well. Cross-compilation from Linux to macOS was super easy thanks to purego, no cross-compiler needed, just `GOOS=darwin GOARCH=arm64`. Plus, discovered that macOS’s arm64 library paths are different!

@nila https://gist.github.com/pojntfx/bc688a887a940e3e458684df62058843

Little hacky packaging script for all of this so far - allows you to build a .dmg for a puregotk #Go #GTK app, all from Linux, code signing included. `go-gettext` still needs a way to specify where to load the `gettext` dylib from when it's not available in the default location, so I stubbed that out, but no other code changes necessary :)

Cross-Compile a puregotk app from Linux to macOS and run it via SSH

Cross-Compile a puregotk app from Linux to macOS and run it via SSH - main-binary.sh

Gist
@nila I doubt I'll be putting much work into the macOS and Windows parts here - for this to actually be useful as in it being a viable way to publish GTK apps to non-Linux platforms while still building on Linux - we'd need a proper auto-updater and Windows support as well, and Flatpak is just too comfortable. I put a bunch of work into this for https://github.com/pojntfx/hydrapp a while back, including a way to auto-update the signed DMGs - maybe some time in the future?
@nila We can run the XCode command line tools and GTK via MacPorts & Darling on Linux running in Docker, and install gcc and GTK via MSYS2 in Wine running in Docker too. Not really puregotk-specific, but would be neat to have a "Flatpak manifest for building GTK apps on non-Linux OSes"-kind of thing some day.

@pojntfx @nila Pixi is a pretty good fit for "cross platform manifests"!

https://prefix.dev

For example, the Pixi manifest for Shortwave, which both works on macOS and Windows (and Linux):

https://gitlab.gnome.org/World/Shortwave/-/blob/pixi/pixi.toml

(WIP - not merged yet)

prefix.dev – solving software package management

The software package management platform for Python, C++, R, Rust and more

prefix.dev
@haeckerfelix @nila Oh hell yeah, that seems like exactly what I'm looking for, thank you for sharing! At first glance it seems mostly for packages, is there a way for me to publish a self-updating .dmg/.msi with this as well? The idea is that on Linux you'd get a nice Flatpak, and then on the proprietary platforms you get a self-updating package :)

@pojntfx @nila the most easiest / straight-forward way would be to publish the app to conda-forge, this way you don't have to deal with self-updates. It's comparable with Flathub, but cross platform.

The Pixi manifest describes the environment which you can use for development (cross platform), for the actual packaging you use a separate recipe file, which describes the needed dependencies + commands to build the app.

For example (WIP)
https://github.com/conda-forge/staged-recipes/pull/32284

Add shortwave recipe by haecker-felix · Pull Request #32284 · conda-forge/staged-recipes

Checklist Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml". License file is packaged (see here for an example). Source is from officia...

GitHub
@haeckerfelix @nila Hmm, that makes sense, but won’t that require the user to install Conda? I’m fine with that in the case of Flatpak since it’s pre-installed, but I feel like non-technical people won’t understand how to install a package manager just to install the app :)

@pojntfx @nila yep, that's something for which there isn't a perfect solution at the moment.

There are two options:
1) Make a "wrapper installer", which installs Pixi on the machine, and then in a second step downloads and installs the actual app from conda-forge. This way you don't have to take care of the update mechanism.

@pojntfx @nila

2) Wrap the Conda package and all of the dependencies in some MSIX / macOS app bundle. This way the user doesn't need some additional package manager, but you have to deal with updates (unless you publish it in MS Store / AppStore).

Oh, and you don't need Conda (the tool), Pixi can be used as global package manager, just like homebrew or winget (but is using the same Conda package format).

@haeckerfelix @nila Makes sense! I'll def. take a look. Publishing to anything other than Linux _and_ having working updates is madness
@pojntfx @nila I got questions about running Maps on macOS once when I did a presentation. Would be kinda cool to see. But I suspect some things would need fixing. For example GeoClue is not running there, so possibly it would need some abstraction for location service (the same would apply for Window, btw). Or maybe it would still run, but unable to get current location.

@mlundblad @nila Yeah, even in my simple case stuff doesn’t fully work (no D-Bus, so no notifications). WebKitGTK isn’t packaged for macOS, that’s a pretty big blocker.

I wonder if it makes sense to put more work into this? I did a bunch of work on the whole “compile for macOS and Windows” in a UNIXy way (Darling for macOS builds in Docker on Linux, MSYS2 for Windows builds on Linux) with https://github.com/pojntfx/hydrapp, but stopped a year ago bc I’d rather just focus on Linux

GitHub - pojntfx/hydrapp: Build fast apps that run everywhere with Go and a browser engine of your choice.

Build fast apps that run everywhere with Go and a browser engine of your choice. - pojntfx/hydrapp

GitHub
@mlundblad @nila But yeah if there is enough interest in it, maybe it’s worth it? I’d love to have smth that just takes a Flatpak manifest + “x-“-prefixed extra keys for macOS (Homebrew) + Windows (MSYS2) packages to install instead of SDKs and runtimes, and then just builds self-updating DMGs and MSIs from it

@pojntfx @mlundblad @nila i want this so badly.

native dev on windows and macos feels completely bananas in 2026 but the current gtk/etc tooling options meant a macos port was a small hassle (for my silly little bookmarking app) and windows wasn’t worth it at all.

i’d rewrite everything in go if it could visit all 3 cities with only minor pain. 😜

@deobald @mlundblad @nila Ha! Maybe I should put work into this then lol. Any chance you could give hydrapp a shot for your use case? I know it's web-based, but conceptually it would allow you to do something like you propose. The DX is also almost untested though so if I were to take a fresh look at it, except this time targetting GTK, having another human take a peak at it would be super valuable https://github.com/pojntfx/hydrapp
GitHub - pojntfx/hydrapp: Build fast apps that run everywhere with Go and a browser engine of your choice.

Build fast apps that run everywhere with Go and a browser engine of your choice. - pojntfx/hydrapp

GitHub
@pojntfx @mlundblad @nila i can’t do pwa but if your xplat go +gtk dx would likely mirror hydrapp, i can give it a shot just for fun sometime. :)
@pojntfx @nila I feel like with a bit of tweaking GTK/Adwaita could become a fantastic option for cross platform desktop dev, one which non-Linux people could adopt. It's got the brand longevity, none of the confusing licensing schemes of Qt, without the baggage of having to learn a new language not used anywhere else (Flutter/Dart), and a really attractive design.
@pojntfx @nila This is awesome to see, as I'll be switching to macOS very soon.
@pojntfx @nila not sure how well this bodes with all the accusations of GTK4 looking like modern Mac Styles
@disaster2life @nila @pojntfx I don't understand your toot tbh. Yes, GNOME design-wise is closer to MacOS… So what? What about it? KDE apps are closer to Windows' design and what about it?
@tragivictoria @nila @pojntfx oh nothing, mostly just a joke (for me) most people seem to accuse that it looks like MacOS and I don't mind it