iOS, Nostr, and the Key You Think You Own

• What iOS sandboxing actually does
• Why Amber does not exist on iOS
• The real weakest link: backup
• What sovereign mobile signing actually looks like
• The uncomfortable conclusion

Your iOS Nostr client does not isolate your nsec from itself.

This is the sentence most mobile Nostr users have not considered. iOS sandboxing is a real security property — but it protects apps from each other, not your keys from the app that holds them. If your nsec lives inside the client, the client has it. Full stop.

§What iOS sandboxing actually does

Apple’s sandbox model restricts what apps can see across the system. Your Nostr client cannot read your banking app’s data. Your banking app cannot read your Nostr client’s data. That is the guarantee.

What it does not do: prevent your Nostr client from exfiltrating your nsec if it decides to, storing it in cleartext, syncing it to a third-party server, or logging it in a crash report. The sandbox boundary is between apps. Your nsec is inside the app. The threat is not cross-app access. The threat is the app itself.

§Why Amber does not exist on iOS

Amber works on Android because Android’s permission model allows inter-app communication with defined contracts. One app can send a signing request to another app, receive the signed event back, and never share the underlying key. The key stays in the signer. The client stays blind.

Apple does not allow this model. iOS sandboxing is so complete that a shared signer would require either a background daemon — which Apple can terminate at any time — or a network hop to a server you do not control. Both paths move the key away from you. Apple did not build this to harm Nostr users. It built it to simplify the security model for a mass-market device. The consequence for key sovereignty is the same either way.

This is not a tooling gap that will close when someone writes the right library. It is a platform decision. Amber on iOS is not coming.

§The real weakest link: backup

Assume for a moment you have a client you trust. You have read the code. You believe it handles your nsec correctly. You are still one backup decision away from losing everything.

Most iOS users store their nsec in one of three places: a screenshot in their camera roll, a note in Apple Notes synced to iCloud, or a password manager with cloud sync. All three of these give Apple — or anyone who compromises your iCloud account — access to your Nostr identity. The signing process can be perfect. The backup makes it irrelevant.

The nsec is not a password. Changing it means abandoning your identity. There is no reset. This asymmetry matters: a compromised iCloud password costs you two-factor recovery time. A compromised nsec costs you your entire Nostr history, your follower graph, and every web-of-trust connection you have built.

§What sovereign mobile signing actually looks like

NIP-46 separates the key from the client. The signer runs in one place. The client runs in another. They communicate through encrypted messages over Nostr relays. The client never sees the key.

On iOS, this architecture is not a workaround. It is the only path that gives you genuine key isolation. Run a NIP-46 signer on your home machine — Nsecbunker, nostr-signing-device, or any implementation you control. The iOS client connects to the signer over Tor, Tailscale, or a relay you trust. The phone carries a session token, not the key.

This is not more complicated than it sounds. It is more setup than most users want. That is the honest tradeoff: convenience versus sovereignty, not convenience versus nothing.

§The uncomfortable conclusion

Nostr’s identity model is more ambitious than Bitcoin’s UTXO model in one specific way: your Nostr identity is your social graph, your reputation, and your communication channel — not just money. Losing your Bitcoin private key loses your coins. Losing your Nostr nsec loses your identity.

The tooling gap is not technical. The architecture for sovereign mobile signing exists today. The gap is that most Nostr clients present themselves as sovereign by default when they are not. “Your keys, your identity” printed on the app store listing is true in the same sense that “not your keys, not your coins” is true for an exchange — technically accurate, selectively applied.

The clients that handle keys well are the ones that are honest about what they do not do. If your client does not support NIP-46 and does not tell you where it stores your nsec, that is the answer.