The main difference that springs to mind is which docker builder is being used and the context provided to the builder.
When using a recent version of flyctl, it will likely default to using a remote builder provided by Fly.io on both linux and macos. Some developers have had issues with the local docker builders on macos. the output from fly launch will indicate if it used the local builder or a remote builder. If a local builder is getting used by default, pass the --remote-only flag to force fly launch to use a remote builder instead.
The docker context may be different between linux and macos. For example, if some binaries are built locally and then copied into the docker image, the versions that are built on macos are not likely to work in the linux/x86_64 docker images that are built when deploying to Fly. One way to fix that is to ensure that all the “building” happens within docker, and use a .dockerignore file to ensure that any locally generated build artifacts are not passed into the docker build context.
I tried running fly launch on a macos device for the linked PR, and the docker build failed due to a missing Cargo.toml file. I didn’t investigate further, but that could be an indication that the docker build is relying on some artifacts that are built on the host system.