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.
Which sharing route should I use?
Revault has three ways to share files. The right one depends on what your recipient uses and whether the share needs limits.
Between two iPhones, when you do not need limits, iOS offers a private, read-only CloudKit invitation between Apple accounts. It does not enforce access counts or automatic expiry, so access lasts until you stop sharing.
Between any two phones, when limits matter, use a controlled server share. It works from iPhone to Android, between Android phones and between iPhones. You set an expiry within 30 days and can add a maximum number of access sessions, export permission and a timer after first access. The recipient needs the Revault app and your separate secret, but no Revault account.
For someone who only has a browser, share a single file with a web share link. It works for completed Revault cloud uploads, and anyone holding the complete link can download that file without an account. Web links expire after one hour, one day or seven days. The iOS and Android apps are not yet available in the App Store or Google Play, so a web link is the simpler route when your recipient does not already have Revault.
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.
A share holds the files as they were when you created it. Later edits in your vault do not reach the recipient, and your folders, tags and favourites stay private.
Set the recipient’s access window
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.
A worked example: sending a lease from an iPhone to an Android phone
Say your partner uses an Android phone and needs your signed lease for a few days while arranging insurance. Unlock your vault on your iPhone and select only the lease, not the whole folder of housing documents.
Create a controlled server share, because a CloudKit invitation works only between Apple accounts. Set the expiry to a week and allow a few access sessions. Each session lasts at most 15 minutes, so a few sessions leave room for your partner to reopen the lease. Allow export only if they need to keep their own encrypted copy.
Send the invitation link by message, then read the secret out on a call. Your partner opens the link in Revault on their Android phone, enters the secret and sees the lease in an isolated, read-only shared vault. Their own vaults stay locked, and they never see your pattern or recovery key.
When the paperwork is done, revoke the invitation rather than waiting for it to expire. Deleting the lease from your own vault would not cancel the share.
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.
What the server sees during a share
Cross-platform shares travel through Revault’s server in bounded encrypted parts, each with a SHA-256 checksum. The service records operational metadata: file sizes, checksums, timestamps and how many access sessions it has granted.
It never receives your vault pattern, recovery key or vault master key, because none of them are included in a share. The decryption secret you give the recipient is never uploaded. The invitation’s read and management capabilities are stored on the server only as hashes.
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.
What a share can’t undo
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.