[Bug] [macOS] Release binary blocked by Gatekeeper - .app bundle not shipped

[sfrankiel]

Description

The macOS release asset ships a raw binary that is blocked by Gatekeeper on launch. The build system already produces a working .app bundle locally - it just isn't what gets packaged into the release.

Environment

• OS: macOS 15.6.1 (24G90), Apple Silicon (arm64)
• Ferrite version: 0.2.6.1
• Rust version: rustc 1.93.1 (01f6ddf75 2026-02-11) (Homebrew)
• Installation method: pre-built Binary

Steps to Reproduce

1. Download ferrite-macos-arm64.tar.gz from the v0.2.6.1 release
2. Extract the archive
3. Double-click the resulting ferrite binary

Expected Behavior

Application launches

Actual Behavior

Gatekeeper Error appears

Screenshots

Workaround:

Users comfortable with the terminal can run:

bashxattr -d com.apple.quarantine ferrite && ./ferrite 

Additional Context

The release asset ships a raw binary instead of the .app bundle.

A local build via cargo bundle produces a working .app at target/release/bundle/osx/Ferrite.app, which launches without issue. It appears that the release asset ships target/release/ferrite or target/release/bundle/osx/Ferrite.app/Contents/MacOS/ferrite (raw binaries) instead of the Ferrite.app bundle.

Release asset contents after extraction:

ferrite  ← raw Mach-O binary

Local build via cargo bundle produces:

target/release/bundle/osx/Ferrite.app/  ← proper .app bundle
└── Contents/
    ├── Info.plist
    ├── MacOS/
    │   └── ferrite
    └── Resources/

macOS requires the .app bundle structure - not just the raw binary - to treat the application as trusted and launch it correctly.

[OlaProeis]

Hi @sfrankiel

Thanks for the detailed report! You've identified the exact issue - our CI workflow is packaging the raw binary instead of the proper .app bundle.

You're absolutely right that cargo bundle produces a working target/release/bundle/osx/Ferrite.app locally. The problem is in our release workflow which just grabs the binary from target/release/ferrite and ships it in a tar.gz.

I've added this to the v0.2.7 roadmap. The fix involves:

1. Installing cargo-bundle in the macOS CI job
2. Running cargo bundle --release to generate the proper .app structure
3. Packaging Ferrite.app as a .zip (which is the standard format for macOS app distribution)

Regarding code signing: We have free code signing for Windows through SignPath Foundation, but Apple's ecosystem is more restrictive(costly :P). For now, shipping the proper .app bundle structure will at least allow users to:

1. Move the app to Applications folder
2. Right-click → Open (to bypass the "unidentified developer" warning)
3. Or use your workaround: xattr -d com.apple.quarantine Ferrite.app

This is significantly better than the current raw binary which triggers Gatekeeper immediately on double-click.

I'll update this issue once the CI fix is in place. Thanks again for the clear reproduction steps!

[OlaProeis]

Hi @sfrankiel! This has been fixed in v0.2.7 which just released today.

The release workflow now properly packages the .app bundle built via cargo-bundle instead of shipping the raw binary. The v0.2.7 release includes:

• ferrite-macos-arm64.dmg — Apple Silicon
• ferrite-macos-x86_64.dmg — Intel Macs

Both contain proper Ferrite.app bundles that launch without Gatekeeper blocking.

The workaround (xattr -d com.apple.quarantine) should no longer be needed. Please download v0.2.7 and let us know if the .app bundle launches correctly!

[optionals]

Hi @sfrankiel! This has been fixed in v0.2.7 which just released today.

The release workflow now properly packages the .app bundle built via cargo-bundle instead of shipping the raw binary. The v0.2.7 release includes:

• ferrite-macos-arm64.dmg — Apple Silicon
• ferrite-macos-x86_64.dmg — Intel Macs

Both contain proper Ferrite.app bundles that launch without Gatekeeper blocking.

The workaround (xattr -d com.apple.quarantine) should no longer be needed. Please download v0.2.7 and let us know if the .app bundle launches correctly!

https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.7
ferrite-macos-arm64.dmg and ferrite-macos-x86_64.dmg not in Asserts

[OlaProeis]

@optionals @sfrankiel

I messed up, but fixed now, i deleted the old release and pushed with the same tags, so now the .dmg is there.

Please let me know if its working fine!

[optionals]

@optionals @sfrankiel

I messed up, but fixed now, i deleted the old release and pushed with the same tags, so now the .dmg is there.

Please let me know if its working fine!

The new release includes dmg, but it is still been blocked

[optionals]

[OlaProeis]

@optionals

because Ferrite is not notarized (we don't have an Apple Developer Program license — $99/year), Gatekeeper will still show a warning dialog on first launch. Here are the ways to handle it:

Option 1: Homebrew (Recommended — Zero Warnings)

We've set up a Homebrew tap with a Cask that automatically strips the quarantine attribute:

brew tap olaproeis/ferrite
brew install --cask ferrite

This installs Ferrite.app to /Applications with no Gatekeeper friction at all.

Option 2: Manual Bypass After DMG Install

After dragging Ferrite.app to Applications from the DMG:

• Right-click → Open (may need to do this twice on macOS Sequoia)
• Or: System Settings → Privacy & Security → scroll down → click "Open Anyway" (appears after a blocked launch attempt)
• Or terminal: xattr -cr /Applications/Ferrite.app

Why This Happens

Apple requires:

1. A paid Developer ID certificate ($99/year)
2. App notarization (Apple scans and approves the binary)

Without both, macOS shows warnings. The app is safe — you can audit the source or build from source with cargo build --release.

We've also updated the release notes and README with clearer macOS instructions.

[optionals]

@optionals

because Ferrite is not notarized (we don't have an Apple Developer Program license — $99/year), Gatekeeper will still show a warning dialog on first launch. Here are the ways to handle it:

Option 1: Homebrew (Recommended — Zero Warnings)

We've set up a Homebrew tap with a Cask that automatically strips the quarantine attribute:

brew tap olaproeis/ferrite
brew install --cask ferrite

This installs Ferrite.app to /Applications with no Gatekeeper friction at all.

Option 2: Manual Bypass After DMG Install

After dragging Ferrite.app to Applications from the DMG:

• Right-click → Open (may need to do this twice on macOS Sequoia)
• Or: System Settings → Privacy & Security → scroll down → click "Open Anyway" (appears after a blocked launch attempt)
• Or terminal: xattr -cr /Applications/Ferrite.app

Why This Happens

Apple requires:

1. A paid Developer ID certificate ($99/year)
2. App notarization (Apple scans and approves the binary)

Without both, macOS shows warnings. The app is safe — you can audit the source or build from source with cargo build --release.

We've also updated the release notes and README with clearer macOS instructions.

I see

[OlaProeis]

Closing as fixed in v0.2.7. The release now ships proper .app bundles in DMGs instead of raw binaries.

As noted in the discussion, Ferrite isn't notarized (requires Apple Developer Program), so a first-launch warning will still appear. Use Homebrew (brew tap olaproeis/ferrite && brew install --cask ferrite) for zero-friction installation, or see the README macOS section for other workarounds.

Thanks to @sfrankiel for the excellent bug report and @optionals for helping verify the fix!