Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Tauri Plugin permission-flow
Tauri bindings for the permission-flow macOS permission UI.
The plugin is designed for macOS, but it compiles in cross-platform Tauri
workspaces too. Outside macOS, controller creation still succeeds, flow
commands become no-ops, and host-app status resolves to unknown.

What you get
The Tauri package gives you two layers:
PermissionFlow: a handle-backed controller for opening the floating permission guidance UIauthorizationState(...)andwatchAuthorizationStatus(...): host-app status helpers for reflecting permission state in your frontend
Use the controller when you want to start the flow. Use the status helpers when you want your UI to react to the current host app's permission state.
Install
Add the Rust plugin in your Tauri app's src-tauri/Cargo.toml:
[]
= "0.1.40"
Register it in your Tauri builder:
default
.plugin
Add the JavaScript package:
Because the final macOS executable links the Swift runtime, add this to your
app's src-tauri/build.rs:
Quick start
import {
Permission,
PermissionFlow,
suggestedHostAppPath,
watchAuthorizationStatus,
} from '@veecore/tauri-plugin-permission-flow-api'
const flow = await PermissionFlow.create()
const appPath = await suggestedHostAppPath()
if (appPath) {
await flow.startFlow({
permission: Permission.Accessibility,
appPath,
})
}
const stopWatching = watchAuthorizationStatus(
Permission.Accessibility,
(state) => {
console.log('Current host-app status:', state)
}
)
stopWatching()
await flow.close()
API shape
startFlow accepts:
permission: one ofPermission.Accessibility,Permission.InputMonitoring,Permission.ScreenRecording,Permission.AppManagement,Permission.Bluetooth,Permission.DeveloperTools,Permission.FullDiskAccess, orPermission.MediaAppleMusicappPath: the app bundle path to suggest inside the permission flowuseClickSourceFrame: optional, defaults totrue
suggestedHostAppPath():
- returns a best-effort
.appbundle path for the current launch context - is a good default for examples, dev builds, IDE-integrated terminals, and bundled Tauri apps
- returns
nullwhen there is no meaningful host app bundle to infer
watchAuthorizationStatus:
- immediately publishes the current host-app status by default, even if it was already granted before your app started
- then republishes only when the status actually changes
- refreshes on window focus, on visibility changes, and on a light interval by default
- returns a cleanup function you can call when your UI unmounts
Example app
The repo includes a tiny demo app under
crates/tauri-plugin-permission-flow/examples/tauri-app.
It intentionally stays minimal:
- one permission picker
- one button
- button state driven by the host-app authorization watcher
Notes
- This plugin is intended for macOS.
PermissionFlowis a Tauri resource handle. It owns one native controller on Tauri's main thread and marshals calls there internally.- The JS wrapper now adds best-effort garbage-collection cleanup through
FinalizationRegistry, butclose()is still the deterministic and recommended cleanup path. authorizationState(...)andwatchAuthorizationStatus(...)are host-app status helpers. On macOS, the public permission-status APIs used bypermission-flowdescribe the current host app or host process, not an arbitrary.appbundle path.- In other words,
appPathcontrols which app bundle appears in the floating guidance flow, but it should not be confused with an authoritative "does that target app already have permission?" check.
Maintainer Note
The guest package is published from GitHub Actions through npm trusted
publishing. The repository workflow lives at
.github/workflows/publish-npm.yml.