permission-flow
permission-flow provides a Rust-friendly API for presenting the macOS
permission guidance flow backed by the Swift/AppKit implementation in this
workspace.

What it does
- Creates a
PermissionFlowControlleron the macOS main thread - Starts guided flows for supported privacy panes
- Infers a likely host app bundle with
AppPath::suggested_host_app() - Exposes host-app permission status checks through
Permission::authorization_state()
Supported permissions:
- Accessibility
- Input Monitoring
- Screen Recording
- App Management
- Bluetooth
- Developer Tools
- Full Disk Access
- Media & Apple Music
Quick start
use ;
let controller = new?;
let app_path = suggested_host_app
.expect;
controller.start_flow?;
# Ok::
Platform behavior
This crate is designed for macOS, but it now compiles on other operating systems too.
Outside macOS:
PermissionFlowController::new()succeeds with a no-op controllerstart_flow()andstop_current_flow()become no-opsPermission::authorization_state()returnsPermissionAuthorizationState::UnknownAppPath::suggested_host_app()returnsNone
That keeps cross-platform Rust workspaces buildable without pretending the actual macOS permission UI exists on those platforms.
Important status warning
Permission::authorization_state() reports what the current host process or
host app can determine about its own permission state.
It does not authoritatively answer whether an arbitrary target .app
bundle already has the requested permission.
This means:
- if the target app is the current host app, the status is meaningful
- if the target app is some other app bundle, treat the status as host-app information only
Runtime note
Because the final macOS executable links Swift runtime libraries, downstream
binary crates currently need this in their build.rs:
Acknowledgements
The Swift side of this crate builds on top of the excellent
PermissionFlow project and
uses swift-rs for the bridge into
Rust.