RuView Desktop 0.3 won't open on macOS

[mknippen]

Steps:

1. Downladed RuView Desktop 0.3 (Apple Silicon) from the releases page
2. Extracted file, moved to Applications
3. Tried Right-Click open (as well as regular)

This screen appears

NOTE: This is not the standard gatekeeper message. Normally, if you don't have gatekeeper, you can bypass in Settings. Nothing pops up in settings, and there is no other option.

MacBook Pro M3 Max
OS: Tahoe 26.3

[ruvnet]

Works for me.

[ruvnet]

Workaround

This happens because the app isn't signed with an Apple Developer certificate yet. macOS quarantines apps downloaded from the internet.

To fix, run this in Terminal:

xattr -cr /Applications/RuView\ Desktop.app

Then try opening the app again. This removes the quarantine attribute that triggers Gatekeeper.

---

Proper Fix (for maintainers)

To properly resolve this for all users, the app needs to be:

1. Code signed with an Apple Developer ID certificate
2. Notarized via Apple's notarization service

This requires:

• An Apple Developer account ($99/year)
• Adding signing credentials to the GitHub Actions workflow

The Tauri docs cover this: https://v2.tauri.app/distribute/sign/macos/

I'll update the release notes with the workaround instructions for now.

[ruvnet]

Update: "App is damaged" error

If you get "App is damaged" even after xattr -cr, try this complete process:

# 1. Remove quarantine and clear extended attributes
xattr -cr /Applications/RuView\ Desktop.app

# 2. Re-sign the app with ad-hoc signature
codesign --force --deep --sign - /Applications/RuView\ Desktop.app

# 3. Now open the app
open /Applications/RuView\ Desktop.app

Why this happens: The app is currently built with an ad-hoc signature (not an Apple Developer certificate). macOS Tahoe (26.x) has stricter Gatekeeper requirements.

Alternative: Run directly from Terminal:

/Applications/RuView\ Desktop.app/Contents/MacOS/wifi-densepose-desktop

---

We're tracking code signing setup in the build pipeline. For now, the above workaround should allow you to run the app.

[ruvnet]

BTW, the desktop app is super Alpha. I'm in the midst of creating it.

[aniruddhaadak80]

The maintainer workaround makes sense as a short-term path, but the real fix is still proper signing and notarization in the release process. When macOS blocks the app in a way that does not expose the normal bypass flow, it usually means the quarantine or signature state is unusual enough that user-level workarounds become brittle.

If the xattr path does not fully solve it, the next useful check is whether the binary is carrying inconsistent attributes after download. That would help confirm whether the issue is packaging, distribution, or something specific to the current build artifact.

[mknippen]

Running the xattr command allowed the app to launch. However, the flashing tool does not show any ports available, even when I have an ESP32-S3 plugged in.

EDIT: Fixed in 0.4.1