Long-Press Context Menus for a Gallery Item in a Rork Expo App

Building the native menu with zeego

Installation goes through Expo cleanly.

npx expo install zeego react-native-ios-context-menu react-native-ios-utilities

Here is the smallest setup that makes a single card menu-aware. A long press raises the menu, and Preview receives the preview content.

import * as ContextMenu from "zeego/context-menu";
import { Image } from "expo-image";
 
function WallpaperCard({ item, onSave, onShare, onFavorite }) {
  return (
    <ContextMenu.Root>
      <ContextMenu.Trigger>
        <Image source={item.thumb} style={styles.card} recyclingKey={item.id} />
      </ContextMenu.Trigger>
 
      <ContextMenu.Content>
        <ContextMenu.Preview>
          {() => <Image source={item.full} style={styles.preview} />}
        </ContextMenu.Preview>
 
        <ContextMenu.Item key="save" onSelect={() => onSave(item)}>
          <ContextMenu.ItemTitle>Save to Photos</ContextMenu.ItemTitle>
        </ContextMenu.Item>
        <ContextMenu.Item key="share" onSelect={() => onShare(item)}>
          <ContextMenu.ItemTitle>Share</ContextMenu.ItemTitle>
        </ContextMenu.Item>
        <ContextMenu.Item key="fav" onSelect={() => onFavorite(item)}>
          <ContextMenu.ItemTitle>Favorite</ContextMenu.ItemTitle>
        </ContextMenu.Item>
      </ContextMenu.Content>
    </ContextMenu.Root>
  );
}

The point that matters here: the preview is fed the high-resolution item.full, not the thumbnail. If a low-res image gets scaled up the moment the card lifts, the softness is glaring and the whole effect backfires. The preview only lives for the instant before your finger releases, so loading the large image at exactly that moment is a design that pays off.

Resolving the scroll-versus-long-press conflict

The first pitfall I hit in the masonry gallery was the menu opening mid-scroll. The instant a finger lands gets misread as a long press. Dull the detection too much, though, and it flips into "I am holding it and nothing happens."

The sweet spot was delaying the long-press decision just slightly beyond the default. Give the trigger wrapper a delayLongPress to separate it from the start of a scroll and avoid the misfire.

<ContextMenu.Trigger>
  <Pressable delayLongPress={400} android_disableSound>
    <Image source={item.thumb} style={styles.card} recyclingKey={item.id} />
  </Pressable>
</ContextMenu.Trigger>

In my case around 400ms was the border between accidental fires and frustration. At 250ms it went off the moment a scroll began; past 600ms it felt sluggish. Pair that with a single light haptic the instant the long press commits — it becomes a small warning under the finger before the target lifts, and makes an unwanted gesture easy to cancel. I recommend one gentle pulse and no more.

import * as Haptics from "expo-haptics";
 
// once, when the long press commits
Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Medium);

The trick with haptics is not to hammer them. A strong buzz every time the menu opens ends up feeling cheap. Once, and gently.

Making save and share actually work

A menu item is only finished when the side effect behind it is finished too, not just the label. Saving to Photos is the heart of a wallpaper app, so make the permission request and the save the shortest path possible.

import * as MediaLibrary from "expo-media-library";
import * as FileSystem from "expo-file-system";
import { Share } from "react-native";
 
async function saveToPhotos(item) {
  const { status } = await MediaLibrary.requestPermissionsAsync();
  if (status !== "granted") {
    // On denial, guide the user to Settings (never fail silently)
    return promptOpenSettings();
  }
  const local = await FileSystem.downloadAsync(
    item.full,
    FileSystem.cacheDirectory + item.id + ".jpg"
  );
  await MediaLibrary.saveToLibraryAsync(local.uri);
  Haptics.notificationAsync(Haptics.NotificationFeedbackType.Success);
}
 
async function shareWallpaper(item) {
  await Share.share({ url: item.full, message: item.title });
}

Nothing happening when a save is denied is the most disappointing outcome of all. If permission is missing, surface a path to the Settings app. If the save succeeds, return a success haptic. Adding just those two turns the menu from "pressable decoration" into a feature people actually use.

Switch to a custom overlay on Android

zeego shows a menu on Android too, but not the lifting preview iOS gives you. In a wallpaper app, seeing the image large is the value, so on Android I leaned into a custom overlay with its own preview. A long press lays down a translucent backdrop, enlarges the target in the center, and lines up the same three actions below.

import { Platform } from "react-native";
import Animated, { FadeIn } from "react-native-reanimated";
 
function GalleryItem(props) {
  if (Platform.OS === "ios") return <WallpaperCard {...props} />;
 
  // Android: open a custom overlay from onLongPress
  return (
    <Pressable
      delayLongPress={400}
      onPress={props.onOpen}
      onLongPress={() => {
        Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Medium);
        props.openOverlay(props.item);
      }}
    >
      <Image source={props.item.thumb} style={styles.card} recyclingKey={props.item.id} />
    </Pressable>
  );
}

Keep a single overlay at the top of the screen and swap the open item through state. Giving each card its own overlay collides with list virtualization and inflates memory. "One heavy decoration, outside the list" is the same instinct you use when building a masonry layout. For the column distribution and layout foundation, I wrote up the details in laying out variable-height images in columns.

Acceptance checks and wrap-up

Before calling it done, I verify three things on a real device. Fast, continuous scrolling never triggers the menu by accident. The high-resolution preview arrives in time and is not scaled up softly. And denying a save surfaces a path to Settings. When those three line up, the long press stops being a hidden convenience and becomes a natural gesture people discover by touch.

As a next step, try varying the menu items by state. Turn "Save" into "Saved" for a wallpaper already in the library; flip the star for a favorite. zeego builds its items from state, so once you get here the list itself grows quietly smarter.

It is a single long press, but meeting the expectation already in an iOS user's hands is a quiet, real kind of satisfaction. I hope this helps with your own implementation, and thank you for reading.