Sending a sensitive file between an iPhone and an Android phone should not mean handing over the keys to your whole vault. Revault separates the shared snapshot from your personal vault. This guide walks through the handoff, from selecting a small set of files to helping the recipient open them privately.
Start with the smallest useful snapshot
Unlock your vault on the sending phone and review exactly what you intend to send. Select the relevant files or create a vault snapshot. Check the contents of document scans and photographs before sharing: encryption cannot remove an address, account number, or face that you did not mean to include. Redact unnecessary details before importing the copy you will share.
Recipients receive the files captured when you create the share. Later edits to your source vault are not synced into it. Folder membership, tags, and favourite status are omitted from the shared file metadata. Deleting the original file does not revoke the separate share; manage the invitation itself.
Set the recipient’s access window
Controlled shares use Revault’s server on both platforms, including iPhone-to-iPhone when you need access limits or expiry. iOS also offers private, read-only CloudKit invitations between Apple accounts. Those CloudKit invitations do not enforce access counts or automatic expiry.
For an iPhone-to-Android or Android-to-Android handoff, use a controlled server invitation. Set an expiry within 30 days, decide how many access sessions are appropriate, and choose whether the recipient can export an encrypted copy. If the files are only needed briefly after opening, add a first-access timer as well. The current server sharing service accepts snapshots with up to 1 GiB of file content; that capacity does not limit your local vault files.
Deliver the link and secret separately
The invitation link provides access to an encrypted package; the share secret unlocks its contents. Send the link through your usual channel, verify who will receive the secret, and use a separate private channel for that secret. For example, confirm the recipient on a call rather than placing both pieces in the same forwarded message. Anyone with both pieces can potentially access the share within its limits.
Your vault pattern, recovery key, and vault master key are never included in a share. The service receives encrypted file data and operational metadata such as sizes, checksums, timestamps, and access-session counts. The separate decryption secret is not uploaded.
Open the shared vault and close the handoff
The recipient needs Revault installed. Opening the invitation starts a dedicated flow that requests the sender’s separate secret. It does not ask for a personal vault pattern or require creating a Revault account. The shared files appear in an isolated, read-only vault; the recipient’s personal vaults remain locked. Closing or backgrounding the shared vault clears its active decryption keys and temporary previews.
Expiry and revocation stop future retrieval through Revault. They cannot erase screenshots, exported files, or copies retained by a recipient. Choose someone you trust, even when export is disabled.