[macOS] Native support for Apple Sillicon based Macs

[AlexTMjugador]

The problem Newer Macs are based on the Apple M1 SoC, which uses an ARM64 CPU, instead of a more traditional Intel x64 CPU. These ARM-based Macs are currently not supported by PackSquash. But luckily, because PackSquash is not the only x64 application Mac users would expect to be able to run on these Macs, Apple developed the Rosetta 2 emulation layer to still allow x64 applications to run.

However, Rosetta 2 is likely to be temporary, and the required emulation reduces performance. Moreover, there is anecdotal evidence of a PackSquash user who owns an Apple M1 Mac and had trouble getting it to work, possibly due to architecture mismatches between the PackSquash binary and the GStreamer libraries that were installed by Homebrew. This situation wasn't debugged further because that user was satisfied with running PackSquash in a better supported platform, I don't have an M1 Mac and neither I'm interested in getting one, and GitHub Actions runners for macOS still use Intel CPUs.

The downsides and complications stated in the paragraph above justify investing some effort on making a proper ARM PackSquash port for macOS.

Current technical situation Rust binaries without C dependencies have already been compiled for x64 and ARM in two passes, and then bundled together in a "fat binary" that runs native code on both platforms. This is not directly supported by Cargo yet, although it is not that difficult to manually run additional commands in a CI workflow.

But PackSquash depends on C libraries (GStreamer), and development files for those libraries are installed via Homebrew, which presumably chooses the native architecture, and the last time I checked there was no proper multiarch support in Homebrew, or viable alternatives to Homebrew that supported multiarch. As macOS runners are Intel-based, effective cross-compilation in this scenario is likely to be more complicated, and hasn't been explored as much as the case with pure Rust binaries. There are a number of things that could go wrong with pkgconfig, and due to Murphy's law and my previous experience with getting things to compile on different platforms in CI, they will likely go wrong.

Moreover, in general, the ecosystem for universal binaries is still relatively young and closed. The supported methods to generate such binaries depend on Xcode components which are not really meant to make development with third-party toolchains a breeze, and some of them are already supposedly deprecated. It may be wise to wait some time for things to stabilize and documentation to improve.

What you can do as an Apple Sillicon-based Mac owner You can't change the statu quo by yourself. But you could reach out to the PackSquash developers to test experimental MacOS ARM builds when they become available, or even better yet, if you own an older, Intel-based Mac too, share a method to build PackSquash that can be integrated in a GitHub Actions workflow. This testing in actual Mac devices would give reasons to mark the PackSquash Mac ports as fully supported, too.

What you can do as an Intel-based Mac owner Mostly nothing, as this issue does not really affect you. Reportedly, some users are running PackSquash on their older Macs flawlessly. But I have no idea if they found any difficulty or quirk that is not documented and that does not happen in other ports. Feedback about your experience would be appreciated.

Alternative solutions We could do nothing and rely on Rosetta 2 forever, but doing so is not desirable for end users and not a forward-looking move. This should be properly addressed at some point.

[mikroskeem]

I have Nix derivation around for PackSquash, which is capable of building this for x86_64 and aarch64 Linux & macOS.

I can try upstreaming it if interested.

[AlexTMjugador]

Thank you very much for your comment, @mikroskeem! :heart:

I'd be really interested in a Nix-based workflow for generating ARM64 macOS builds, especially if it generates universal binaries that run natively on both x64 and ARM64 Macs (I'd rather not complicate the choices the end user has to make, the installation guide, and the CI workflows, but something is better than nothing anyway). I don't think Nix would be that relevant for Linux builds, as Linux is supported pretty well for now, unless the Nix package manager/NixOS somehow manages to get things like this working: https://github.com/ComunidadAylas/PackSquash-action/issues/8.

Please feel free to open a PR, join our Discord server, or get in touch privately with me on Discord to discuss the plan and the changes.

[AlexTMjugador]

61de25e dropped the dependency on GStreamer, which was noted as a potential pain point for distribution in general, and making this improvement happen in particular.

[AlexTMjugador]

2ee2db34 added the necessary CI tasks to generate universal binaries. Unless some unexpected technical issue arises, the next PackSquash release for MacOS will be distributed in universal binaries. Space-conscious users can use tools such as lipo to extract the architecture-specific binary from the fat binary.