Writing to the clipboard is quiet. Reading it is something the phone tells the user about.

What is actually in your project for this?

Start by throwing away half of what you will find online. The Clipboard page on reactnative.dev is marked Removed from React Native, and tells you to use one of the community packages instead. It names no replacement. So every tutorial that imports Clipboard from react-native is broken, no matter how recent it looks, and that is most of them.

What an Expo project has instead is the expo-clipboard module, installed with npx expo install expo-clipboard, and listed by Expo as included in Expo Go. That last detail saves an afternoon: you can exercise the clipboard without a native rebuild. The surface is small enough to hold in your head. Text goes in and out through setStringAsync and getStringAsync, images through setImageAsync and getImageAsync, and each of those has a question form, hasStringAsync and hasImageAsync, that tells you whether there is anything there.

Three things in that module bite people. The URL calls, setUrlAsync, getUrlAsync and hasUrlAsync, are documented as iOS and macOS only, so any feature built on them needs an Android path or it is a feature half your users do not have. A write resolves to true on iOS and Android whatever happens, so the return value is not a success check. And the change listener, addClipboardListener, is documented as a no-op on web and macOS, which means a feature built on it behaves differently per platform before you have written a line of your own logic.

If the project runs on web as well, there is a third rulebook. Expo's documentation says a web read prompts the user for permission to see text and images copied to the clipboard, and that the question form needs the same permission, which is the opposite of the native behaviour where asking is free. It also warns that the underlying browser API behaves differently between browsers. None of this is a reason to avoid the clipboard. It is a reason to know which platform you are testing on, a habit that matters as much here as it does anywhere else in building React Native apps without coding.

Does either platform tell the user when your app reads the clipboard?

Both do, in writing, on their own reference pages. Apple's UIPasteboard documentation says that starting in iOS 14 the system notifies the user when an app gets general pasteboard content that originates in a different app without user intent, and that the system determines user intent from user interactions such as tapping a system-provided control or pressing Command-V. The same page tells you which calls avoid it: use certain properties to avoid user notifications and alerts when the system does not establish user intent. The list it gives includes numberOfItems, types, hasColors, hasImages, hasStrings, hasURLs and the pattern-detection methods.

Apple describes the same behaviour at two different strengths on two pages, and the difference is worth knowing. The pasteboard reference says the system notifies the user. The UIPasteControl page, which covers iOS 16 and later, says that programmatic pasting raises a user alert that prompts the user for approval before the app gains access to pasteboard contents. A notification is something a user reads afterwards. An approval is something they can refuse. On any phone your customers are holding, plan for the second one.

Google puts its version under a heading that leaves nothing to interpret: system notification shown when your app accesses clipboard data. On Android 12, API level 31, and higher, the system usually shows a toast when your app calls getPrimaryClip, with the text APP pasted from your clipboard. Google then names three cases where it does not appear. Reading clip data your own app put there. Reading repeatedly from a specific app, where only the first read shows the toast. And reading the clip's metadata, through getPrimaryClipDescription rather than the clip itself. That last one is the same escape hatch Apple offers, written by a different company.

One more thing follows from Apple's rule and is easy to miss. The notice is about content that came from somewhere else, so a value your own app put on the clipboard and reads back is not the case either platform is policing. Google states that exception outright. Apple's wording implies it without saying it in those words, so if your feature depends on a silent round trip through the clipboard, test it rather than reasoning about it.

Apple, UIPasteboard reference, read 17 October 2026

What does it cost you to read the clipboard at the wrong moment?

The expensive pattern is the helpful one. An app reads the clipboard when it opens so it can offer to use the referral code, the coupon, the tracking number or the one-time code the user just copied. It feels like a courtesy. What the user gets is an alert on your first screen asking whether your app may read their clipboard, or a toast with your app's name on it saying you pasted from it. They did not ask for anything yet. The read is the first thing your app did.

The fix is the same on both platforms and it is a product decision, not a technical one. Do not read until the user has asked for a paste. On iOS 16 and later there is a control that is itself the request: UIPasteControl, which Apple documents as a button a person taps to place pasteboard contents in your app, and which exists so you can paste without a user prompt. The expo-clipboard module exposes it as ClipboardPasteButton, and the documentation says to render it only when isPasteButtonAvailable reports true, since it needs iOS 16 or later. Everything else falls back to an ordinary button, and an ordinary button is not a system-provided control.

Between those two, use the question form. Apple's own list of notice-free properties includes hasStrings and hasImages, and Google's list of toast-free cases includes reading the clip description instead of the clip. The product version of that is a Paste button you can grey out when there is nothing to paste, without having looked at what the user copied. Checking is also cheap in the other sense. A clipboard read on the launch path is one more thing between the splash screen and the first frame, which is its own discipline, covered in app startup time.

Android closes off the sneaky version entirely, and has since Android 10. Google's privacy changes page for that release says that unless your app is the default input method editor or the app that currently has focus, your app cannot access clipboard data. So the read on resume trick is not merely rude on Android, it returns nothing. Any feature you design around watching the clipboard while your app is not in front of the user is a feature that does not exist on one of the two platforms you ship to.

Android Developers, copy and paste, read 17 October 2026

What do you owe the user when your app writes to the clipboard?

Two things, and one of them changed recently enough that most code gets it wrong. The first is feedback, and whether you provide it depends on the Android version. From Android 13 the system shows a standard visual confirmation when content is added to the clipboard, which both confirms the copy and previews what was copied. Google strongly recommends removing the toast or snackbar you show after an in-app copy on Android 13 and higher, and still recommends showing one on Android 12L, API level 32, and lower. Apple documents no system confirmation for a write, so on iOS the Copied message is yours to give or withhold.

The second is the one worth stopping for. That Android 13 preview shows the copied value to anyone looking at the screen. If your app has a Copy button next to an API key, a recovery code, a password or a card number, that value is now on display. Google's guide says you must add a flag to the clip description before putting it on the clipboard, a boolean extra called EXTRA_IS_SENSITIVE, and is unusually blunt about the scope: all apps must do this, regardless of the targeted API level. You do not get to ignore it by building against an older SDK.

In an Expo project that is one option on the write call, android.isSensitive, available on both the text and the image write. One word, and it is the single highest-value line in this whole subject, because a generated app that shows a secret and offers to copy it is a common shape and the flag is almost never set. There is no iOS counterpart in that module, so treat a copied secret on iOS as an ordinary pasteboard item that any app the user opens next can ask for.

One more courtesy that is not in any guideline. The clipboard holds one item at a time, so your write destroys whatever the user had there. Copying something on their behalf, without a tap, costs them the address or the phone number they were in the middle of using. Every rule on this page is a platform rule that will move again at the next release, and keeping up with that movement is a running cost, which is the honest frame for what an app costs to maintain.

Apple, UIPasteboard reference, read 17 October 2026, which documents a notice for reading and none for writing