iOS

Entries go to the data-protection keychain (apple-native-keyring-store, protected feature).

The app must be signed

The data-protection keychain needs the application-identifier entitlement, which only a signed app has.

Write policy

New entries are written with the AfterFirstUnlock policy by default (since 0.2.0): background tasks can read them after the first unlock since boot, even when the screen is locked again. Choose another policy when you build the plugin or a standalone store. Both setters exist only when compiling for iOS, so guard them with #[cfg(target_os = "ios")] in cross-platform code:

use tauri_plugin_keyring_store::{Builder, KeyringStore, WriteAccessibility};

#[cfg(target_os = "ios")]
let plugin = Builder::new()
    .ios_write_accessibility(WriteAccessibility::WhenUnlocked)
    .build();

#[cfg(target_os = "ios")]
let store = KeyringStore::new("com.example.app")
    .with_write_accessibility(WriteAccessibility::WhenUnlocked);

The policy applies to writes only; reads find the entry whatever its policy. A handle made with with_store ignores it.

Entries written before 0.2.0 may still use WhenUnlocked until they are written again (set_password / set_bytes). There is no bulk re-key command.

Locked device

When the entry's policy does not allow access (e.g. WhenUnlocked and the device is locked):

• Normal reads fail with Error::KeychainLocked; over IPC the message is keychain locked or protected data unavailable.
• From Rust, availability() probes the keychain and returns Locked, and the *_for_background helpers return Ok(None) / Ok(false) instead of an error. See Rust backend.