Clipboard UX in Expo apps — copy and paste without flooding users with iOS's paste banner

Make the copy side give reliable feedback

Writing doesn't show a banner, but that creates a different problem: it's hard to tell whether it succeeded. setStringAsync() returns true on success, so the dependable approach is to await it before showing any visual feedback.

import * as Clipboard from "expo-clipboard";
import * as Haptics from "expo-haptics";
 
async function copyInviteCode(code: string, showToast: (msg: string) => void) {
  const ok = await Clipboard.setStringAsync(code);
  if (ok) {
    await Haptics.notificationAsync(Haptics.NotificationFeedbackType.Success);
    showToast("Code copied");
  } else {
    showToast("Couldn't copy. Please try again.");
  }
}

The point here is to not show the toast before awaiting the return value of setStringAsync(). Writing finishes almost instantly, but swallowing a failure leads to the worst outcome of all: the user thinks they copied something, and it was empty. Reserve haptic feedback for success only; a button that buzzes hard on every press feels cheap, so keep it subtle.

Temporarily switching the button label to "Copied" right after the copy and reverting it after a couple of seconds is another nice touch. Pairing it with a toast tends to be too much, so I prefer to pick one or the other.

Where iOS and Android differ

Since you're building cross-platform, it helps to know how the two systems diverge.

The hasStringAsync() gating works on both. The wording and look of the read-time notice are up to the OS, so don't try to suppress it from your app. Sticking to the principle of "only read at a moment that matches a user action" is what works best in the end.

Cleaning up after sensitive data

When you let users copy short-lived secrets like a one-time code or token, plan for what happens after they're done. The clipboard is shared across apps, so leaving sensitive data sitting there keeps it readable from other apps too.

expo-clipboard has no standard API for copying with an expiration. So once the value has served its purpose, either call setStringAsync("") to explicitly clear it, or — better — don't route highly sensitive values through the clipboard at all and have users enter them directly in the app. Android 13 and later has a mechanism for distinguishing sensitive content, but expo-clipboard often can't specify it in detail, so the most reliable stance, in my view, is the blunt one: keep secrets off the clipboard wherever you can.

Values like invite codes, where a leak does little harm, are fine to pass through the clipboard. But deciding app-wide that anything tied to payments or login gets treated separately makes those calls much faster to make.

Pull it together into a reusable hook

Consolidating all of this into a single hook saves you from repeating the same care on every screen.

import { useCallback, useEffect, useState } from "react";
import { AppState } from "react-native";
import * as Clipboard from "expo-clipboard";
 
export function useClipboard() {
  const [canPaste, setCanPaste] = useState(false);
 
  const refresh = useCallback(async () => {
    setCanPaste(await Clipboard.hasStringAsync());
  }, []);
 
  useEffect(() => {
    refresh();
    const sub = AppState.addEventListener("change", (state) => {
      if (state === "active") refresh();
    });
    return () => sub.remove();
  }, [refresh]);
 
  const copy = useCallback(async (value: string) => {
    return Clipboard.setStringAsync(value);
  }, []);
 
  // Reading happens only from a user action on the caller side
  const paste = useCallback(async () => {
    const text = await Clipboard.getStringAsync();
    return text.trim();
  }, []);
 
  const clear = useCallback(async () => {
    await Clipboard.setStringAsync("");
    setCanPaste(false);
  }, []);
 
  return { canPaste, copy, paste, clear, refresh };
}

This hook exposes presence monitoring, writing, explicit reading, and cleanup as separate functions. As long as you honor one rule — never call paste() inside a useEffect, always call it from a button's onPress — the kind of needless banner I started with simply won't happen.

As a next step, grep your own app for where you call getStringAsync. If any of those calls run on mount or on focus, that's your banner source. Just moving that read behind an explicit user action will quietly improve the experience.