Fix: normalize arm64 binary path after --arch arm64 build on native M2 host

[m13v]

Problem

On Codemagic mac_mini_m2 with Xcode 16.4, xcrun swift build --arch arm64 outputs the binary to .build/release/ (the native arch path) instead of .build/arm64-apple-macosx/release/. This caused the "Create universal app bundle" step to fail with ERROR: Missing built binaries every time.

The x86_64 cross-compilation correctly outputs to .build/x86_64-apple-macosx/release/, so only the arm64 binary was missing.

Fix

After the arm64 build, detect if the binary landed in release/ instead of arm64-apple-macosx/release/ and copy it to the expected location. Also copies Sparkle.framework and the SPM resource bundle if present.

This is the fourth fix attempt in this release pipeline:

1. ✅ Group name: omi_desktop → desktop_secrets
2. ✅ Build flags: --triple → --arch
3. ✅ This fix: normalize arm64 output path

[greptile-apps]

Greptile Summary

This PR adds path normalization logic to handle a Swift toolchain quirk on Codemagic's M2 Mac runners. When building with --arch arm64 on native arm64 hardware (M2), Swift outputs binaries to .build/release/ instead of the expected .build/arm64-apple-macosx/release/ directory, breaking the downstream universal binary creation step.

The fix:

• Detects when the arm64 binary lands in the native arch path instead of the arch-specific path
• Copies the binary, Sparkle.framework, and resource bundle to the expected location
• Uses conditional checks to only normalize when needed
• Includes defensive error handling with || true for optional resources

The logic is sound and includes proper validation - the downstream "Create universal app bundle" step already validates both arch-specific binaries exist, so if this normalization fails, the build will fail explicitly rather than producing a broken artifact.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk - it's a defensive workaround for a known CI toolchain quirk
• The fix is well-designed with proper conditionals, defensive error handling, and clear documentation. It only activates when needed (binary in wrong location) and preserves existing behavior otherwise. Downstream validation ensures build failures are explicit if normalization doesn't work. This is the third iteration in a series of fixes for the same pipeline, showing incremental problem-solving.
• No files require special attention

Important Files Changed

Filename	Overview
codemagic.yaml	Adds defensive path normalization for arm64 builds on M2 hosts - copies binary and resources to expected location when Swift outputs to native arch path

_{Last reviewed commit: b79d0bd}

[gemini-code-assist]

Code Review

This pull request introduces a workaround in the Codemagic CI pipeline to handle an inconsistency in the build output path for arm64 architecture on native M2 hosts. The change correctly identifies when the build artifacts are in the wrong location and moves them to the expected path, ensuring downstream steps can find them. My feedback focuses on improving the robustness of the shell script to prevent silent failures.

[gemini-code-assist]

The || true construct suppresses exit codes from the cp command. If these assets exist but fail to copy (e.g., due to permissions), this will mask the error and potentially cause more obscure failures in later build steps. It's better to let the script fail immediately if cp encounters an issue. The preceding [ -d ... ] && check already handles the case where the source directory doesn't exist.

            [ -d "Desktop/.build/release/Sparkle.framework" ] && cp -R "Desktop/.build/release/Sparkle.framework" "Desktop/.build/arm64-apple-macosx/release/"
            [ -d "Desktop/.build/release/Omi Computer_Omi Computer.bundle" ] && cp -R "Desktop/.build/release/Omi Computer_Omi Computer.bundle" "Desktop/.build/arm64-apple-macosx/release/"