Thanks for catching this naming issue! You're right that macos-latest builds on ARM now.

Before I merge, I wanted to discuss options:

1. Just rename (your current PR) - Correct naming, but Intel Mac users won't have a native binary
2. Build both architectures - Add a second job for macos-13 (Intel) so we produce both ferrite-macos-arm64.tar.gz and ferrite-macos-x64.tar.gz

Option 2 would be more work but ensures all Mac users have a native binary. Intel Macs can run ARM binaries via Rosetta 2, but native is always better.

Which approach would you prefer? Happy to merge as-is if you think ARM-only is sufficient, or I can help with the workflow changes if you'd like to add Intel support.

Hi -- the best answer (IMO) would be to provide a universal binary that would run on both architectures. I've helped with the GHA build process for a few other projects to accomplish this and happy to help here if that seems like a reasonable idea.

It's super simple, in general just use the standard rust tooling to make a build for each architecture then combine with lipo like so: https://github.com/espanso/espanso/blob/bf4767e038f86430fdf4bf343bd23cb47810e378/scripts/create_bundle.sh#L37

Thanks @n8henrie for the suggestion and offer to help! A universal binary would be the ideal solution.

@cdfuller - Would you be interested in updating this PR to create a universal binary instead? If not, I'm happy to merge this as-is for now (correctly naming it ARM) and create a follow-up issue to implement universal binaries with @n8henrie's help.

Either way, this PR correctly identifies the issue - the current naming is misleading. Let me know your preference!

Intel Macs can run ARM binaries via Rosetta 2,

You have it backward I think: Rosetta 2 allows Apple silicon (ARM) Macs to run Intel (x86) binaries.

Also, unless it won't increase/double the binary file, having them separated would be better choice I think to keep the app size small.

Ill merge this, and make a separate intel Mac one

Also, unless it won't increase/double the binary file, having them separated would be better choice I think to keep the app size small.

@4goodapp I would respectfully disagree, given that this is not a library or dependency whose size is going have a massive or cascading cost, nor is it a TUI / CLI app aimed at servers or minimally resourced systems.

The file naming error that is being fixed here is ample evidence that plenty of end users will be at best inconvenienced or confused by having to parse the naming convention and map that to their device (x86-darwin? x86_64-darwin? intel-darwin? arm? arm64? aarch64? apple-silicon?).

It's just as likely that non-developer ARM users will download and unwittingly running the Intel version, suffering significantly worse performance (and blaming that on the app).

Ferrite for aarch64-darwin currently registers as 9M (trying to cross-compile a x86_64-darwin version via nix, though I assume it will be similar):

$ ls -lh target/release/ferrite
-rwxr-xr-x 1 n8henrie staff 9.0M Jan 11 09:18 target/release/ferrite

I think the cost of an extra 9M is well worth the (user-facing) simplicity of a single universal build.

Just my 2¢ here, and no disrespect intended; there are certainly contexts in which I would look at +/- 9M differently.

@n8henrie I totally get the UX point for a universal binary... and honestly, 9MB really isn’t much these days. That said, for an app that’s trying to stay lean (basically the opposite of those heavy Electron beasts 😅), every saved MB is kind of a win. On top of that (for now) since the binaries are only on GitHub releases, I’d say 99% of users already know whether they need Apple Silicon or Intel.
Maybe include all versions? but I also think keeping things separate makes it a bit simpler to manage on the build side and keeps the app light. Either way it’s not a huge deal... just my two cents from the “keep it lean” perspective.

Got cross-compilation working. Just confirming, actual is 19M:

$ lipo -create -output ferrite-universal target/release/ferrite target/x86_64-apple-darwin/release/ferrite
$ ls -l ferrite-universal
-rwxr-xr-x 1 n8henrie staff 19477856 Jan 13 14:59 ferrite-universal
$ ls -lh ferrite-universal
-rwxr-xr-x 1 n8henrie staff 19M Jan 13 14:59 ferrite-universal

Thanks for taking the time to get cross-compilation working @n8henrie! Really appreciate the effort

For now, I'm going to go with separate ARM and Intel builds to keep things lean - it fits Ferrite's lightweight philosophy, and users downloading from GitHub releases typically know their architecture.

When we expand distribution (Homebrew, website, etc.) and see user confusion about which to download, universal binaries would definitely be worth revisiting. Your work here will be a great reference for that!