Release artifacts, native runtime behavior, filesystem differences, and local build prerequisites for Windows, macOS, and Linux.
- Release installer types by platform
- Native keychain and dialog behavior
- Local build prerequisites
- Platform-specific failure patterns
Platform setup and environment notes
Scope
R2 Desk Pro ships as a cross-platform desktop app for:
- Windows
- macOS
- Linux
The product workflow is consistent across all three platforms, but installers, native runtime prerequisites, secret storage, and local environment problems differ enough that they need their own reference page.
Release artifacts by platform
Current installer and package targets:
- Windows: NSIS
.exeinstaller and.msi - macOS:
.dmg - Linux:
.deband.AppImage
If you are testing the product for real use, install a release artifact first. Use source builds only when you are doing local development or validating a code change.
Native platform behavior
Across all three platforms:
- File and folder pickers are native OS dialogs.
- Secrets are stored in the platform secret store, not plaintext app config.
- Operational requests stay in the Tauri backend.
- App data and settings paths are exposed in the About panel.
The object browser always uses forward-slash object keys because R2 keys are URL-style paths, even when local filesystem paths use Windows backslashes.
Windows notes
Windows-specific considerations:
- Release and dev runtime paths depend on Microsoft WebView2.
- Local source builds need the Rust toolchain plus Visual Studio build tools.
- Unsigned local binaries can trigger antivirus or EDR heuristics more often on Windows than on macOS or Linux.
- Use a PowerShell or Developer PowerShell environment that handles paths with spaces correctly.
If a release build and a local debug build behave differently on the same machine, test the signed installer output before concluding the product path is broken.
macOS notes
macOS-specific considerations:
- Local source builds require Xcode Command Line Tools.
- macOS may prompt for Keychain access when credentials are first written or read.
- Gatekeeper is more likely to object to unsigned local builds than to a normal release installation path.
- Grant native file and folder access prompts when you intentionally choose local upload or download paths.
If the app fails only on a locally built binary, compare with a packaged release artifact before escalating it as a product defect.
Linux notes
Linux-specific considerations:
- Source builds need the GTK/WebKit dependencies required by Tauri on the target distro.
- Desktop keyring support must be available for secret storage to work properly.
- AppImage behavior can vary by distro more than Windows or macOS installers vary by OS version.
- If an AppImage will not launch, confirm executable permission on the file first.
Linux problems are more likely to be distro-specific. When possible, reproduce on a second distro or compare AppImage vs .deb before treating the behavior as universal.
App data, settings, and local paths
Use the About panel when you need the real local paths instead of guessing them.
The app surfaces:
- application version
- platform
- app data directory
- settings path
That matters when you are:
- checking whether settings actually persisted
- clearing local state after a destructive reset
- comparing behavior across two machines
Filesystem and path behavior
Keep these boundaries clear:
- Local upload, download, and sync paths use native OS paths.
- Bucket and object operations use bucket names and object keys.
- Object keys always use
/, regardless of operating system.
If a local output path looks wrong after a folder download, inspect the selected prefix and the actual object keys before assuming the directory writer is broken.
Recommended platform smoke check
Run this after installation on any platform:
- Launch the app.
- Create or unlock the vault.
- Add a profile and validate it.
- List buckets.
- Upload a small file.
- Download the same file.
- Preview a supported asset.
- Generate a signed URL.
That confirms the install path, vault, profile, transfer, preview, and URL layers on the target machine.
When the issue is probably platform-specific
Treat it as platform-specific first when:
- the same credential works on another machine
- the same bucket operation works on another OS
- the failure happens only in local source builds
- endpoint security software is involved
Use Troubleshooting next when you need the failure-mode decision tree.