Since iOS started showing a banner whenever an app reads the clipboard, a lot of apps were caught quietly doing it on launch. The pasteboard often holds exactly the kind of thing a user did not mean to share, a copied password, an address, a one-time code, so reading it without a reason is a privacy problem, and now a visible one. Apple has added ways to use the clipboard respectfully: check what is there without reading it, and let the user grant access by tapping a paste control. Here is the risk and how to handle the pasteboard well.
Short answer
On iOS, reading the general pasteboard can capture sensitive data the user copied for another purpose, and since iOS 14 the system shows a banner when an app reads it, exposing apps that did so silently. Per Apple's UIPasteboard documentation, you should only read the clipboard in response to an explicit user action, and you can use pattern detection to check what type of content is present without reading the actual value, or a system paste control that grants one-time access without triggering the banner. Treat the pasteboard as shared, sensitive space: do not auto-read it, and do not put sensitive data on the general pasteboard without care.
What you should know
- The clipboard can hold sensitive data: passwords, codes, addresses.
- iOS shows a read banner: since iOS 14, reads are visible to the user.
- Do not auto-read on launch: read only on explicit user action.
- Check type without reading: pattern detection avoids reading the value.
- A paste control grants access cleanly: one-time access without the banner.
What changed with the clipboard banner?
iOS made pasteboard reads visible, which exposed silent access. Starting in iOS 14, when an app reads the general pasteboard, the system briefly shows a banner telling the user the app pasted from another app, so behavior that used to be invisible, an app reading the clipboard the moment it opened, became obvious. That surfaced how common silent clipboard reading was, and many apps changed their behavior in response. The banner is not a punishment so much as transparency: it tells users when their copied content is being accessed. For developers, it means any unnecessary pasteboard read now carries a visible privacy signal, so reading the clipboard without a clear, user-initiated reason looks exactly like the snooping the banner was designed to reveal.
What is the privacy risk?
Both reading and writing the pasteboard can leak data. The table breaks it down.
| Action | Risk |
|---|---|
| Reading the pasteboard on launch | Captures unrelated sensitive content the user copied |
| Reading without user intent | Looks like snooping and triggers the banner |
| Writing sensitive data to the general pasteboard | Other apps can read it |
| Leaving sensitive copied data unmarked | It persists and may sync across devices |
On the read side, accessing the clipboard when the user did not ask exposes whatever they last copied, which is often sensitive and unrelated to your app. On the write side, placing sensitive data such as a password or token on the general pasteboard makes it readable by other apps, and on supported setups it can even sync to other devices. So the pasteboard is shared space in both directions, and treating it as private is the mistake.
How do you use the pasteboard respectfully?
Read only on intent, check before reading, and be careful what you write. Do not read the pasteboard automatically; read it only when the user explicitly acts, such as tapping a paste button, so access matches expectation. When you only need to know whether the clipboard contains a certain kind of content, like a URL or a number, use pattern detection to check the type without reading the actual value, which avoids both the privacy exposure and the banner. For paste interactions, a system paste control lets the user grant one-time access by tapping it, without the read banner, because the tap is the consent. On the write side, avoid putting sensitive data on the general pasteboard, and where you must place something transient, prefer options that limit its lifetime or scope. The rule is that clipboard access should always trace back to a user action.
What to watch out for
The first trap is reading the pasteboard on launch or in the background, which captures unrelated sensitive content and shows the banner, making your app look like it is snooping. The second is writing a password, token, or other secret to the general pasteboard, where other apps can read it. The third is checking content type by reading the value when pattern detection would avoid touching it. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces how your app handles sensitive data, which complements reviewing your pasteboard usage for privacy. The pasteboard behavior itself you adjust in the app, tying reads to user intent.
What to take away
- Reading the iOS pasteboard can capture sensitive data the user copied elsewhere, and since iOS 14 the system shows a banner that exposes silent reads.
- Read the clipboard only in response to an explicit user action, never automatically on launch or in the background.
- Use pattern detection to check content type without reading the value, and a system paste control to grant one-time access without the banner.
- Avoid writing sensitive data to the general pasteboard, and use a pre-submission scan such as PTKD.com to review how your app handles sensitive data.
