Why "Save to Photos" Fails on Only Some Devices in Your Rork App — expo-media-library Permission Scopes and Save Design

If you only save, never ask for read permission

This is the single most important design decision. If your app only "saves an image to Photos" — wallpapers, stickers, generated images — you have no need to read the user's library. expo-media-library has a writeOnly option that requests a save-only grant: on iOS this is "add-only," and on Android it is the minimum permission needed to write.

import * as MediaLibrary from "expo-media-library";
 
// Request only the save permission.
// On iOS this is add-only; on Android, the minimum needed to write.
async function ensureSavePermission(): Promise<boolean> {
  // Check the current state first (don't pop a dialog every time)
  const current = await MediaLibrary.getPermissionsAsync(true); // true = writeOnly
  if (current.granted) return true;
 
  // Only request when undecided or a re-prompt is still allowed
  if (current.canAskAgain) {
    const next = await MediaLibrary.requestPermissionsAsync(true); // writeOnly
    return next.granted;
  }
 
  // canAskAgain false = user permanently denied. The dialog will never show again.
  return false;
}

The first argument to getPermissionsAsync(true) and requestPermissionsAsync(true) is the writeOnly flag. Omit it and request with the default (read + write), and even a save-only app triggers the iOS full-access confirmation or the Android read permission — which, from the user's side, reads as "why does a wallpaper app want to see all my photos?" I once shipped this as a combined read/write request, and the denial rate on the save button was noticeably high. After switching to writeOnly, the dialog text itself changed to "Allow adding to Photos?" and the grant rate went up.

Make the intent explicit in app.json (or app.config) as well.

{
  "expo": {
    "plugins": [
      [
        "expo-media-library",
        {
          "photosPermission": "Used to add your saved wallpaper to your Photos.",
          "savePhotosPermission": "Used to save wallpapers to your Photos.",
          "isAccessMediaLocationEnabled": false
        }
      ]
    ]
  }
}

savePhotosPermission is the text shown in the iOS "add-only" dialog. Scoping that string to the save use case helps both your grant rate and your review explanation.

The save itself — download first, then hand it to createAssetAsync

You cannot pass a remote image URL straight to createAssetAsync. You must download it to local storage first and pass that file path. Drop it into a temp file with expo-file-system, save, then clean up.

import * as FileSystem from "expo-file-system";
import * as MediaLibrary from "expo-media-library";
 
type SaveResult =
  | { ok: true }
  | { ok: false; reason: "permission" | "download" | "save" };
 
async function saveRemoteImage(remoteUrl: string): Promise<SaveResult> {
  // 1. Secure the save (writeOnly) permission
  const allowed = await ensureSavePermission();
  if (!allowed) return { ok: false, reason: "permission" };
 
  // 2. Download to a temp file
  const fileName = `wallpaper-${Date.now()}.jpg`;
  const localPath = FileSystem.cacheDirectory + fileName;
 
  let downloaded;
  try {
    downloaded = await FileSystem.downloadAsync(remoteUrl, localPath);
    if (downloaded.status !== 200) {
      return { ok: false, reason: "download" };
    }
  } catch {
    return { ok: false, reason: "download" };
  }
 
  // 3. Save to the photo library
  try {
    await MediaLibrary.createAssetAsync(downloaded.uri);
    return { ok: true };
  } catch {
    return { ok: false, reason: "save" };
  } finally {
    // 4. Always clean up the temp file, success or not
    await FileSystem.deleteAsync(downloaded.uri, { idempotent: true });
  }
}

The point is that it returns the failure reason split into permission / download / save. Collapse all of that into one catch that shows only "Save failed," and you lose any ability to isolate the cause. I first swallowed this in a single try-catch, and I could never tell whether the review's "won't save" was permission or network — I had to go back and re-instrument logging. Splitting the reason into a type lets you write the UX branch below directly.

The trap when you want to put it in an album

If you only "save," the above is enough. But if you want to collect images into an album dedicated to your app, you add a step. Pass the asset from createAssetAsync to createAlbumAsync or addAssetsToAlbumAsync — and here the iOS/Android difference surfaces.

async function saveToAppAlbum(localUri: string, albumName: string) {
  const asset = await MediaLibrary.createAssetAsync(localUri);
  const album = await MediaLibrary.getAlbumAsync(albumName);
 
  if (album == null) {
    // Create the album if it doesn't exist yet
    await MediaLibrary.createAlbumAsync(albumName, asset, false);
  } else {
    // Add to the existing album.
    // The third argument copyAsset only matters on iOS.
    // false moves the original asset, so it can disappear from "Recents" in Photos.
    await MediaLibrary.addAssetsToAlbumAsync([asset], album, true);
  }
}

The final copyAsset argument of createAlbumAsync and addAssetsToAlbumAsync acts only on iOS. Set it true and the asset is duplicated into the album, so it also stays in the user's "Recents." Set it false and it's a move, which generates a different complaint: "I saved it but can't find it in my camera roll." On Android, MediaStore's structure ignores this argument and always treats it as an add. Verify only on Android, ship with false, and you'll get "it vanished" reports from iOS users — that was the exact order in which I tripped over it. If you run albums, make copyAsset default to true.

Under iOS limited access (only the photos the user selected are allowed), adding to an album may not behave as expected. Leaning on save-only writeOnly keeps you largely clear of read-side limited-access effects too, which is another reason writeOnly is the safe choice.

Save at the device's resolution

For an image used full-screen, like a wallpaper, downsampling to the device's logical resolution before saving avoids leaving needlessly huge files in Photos. Downsample with expo-image-manipulator, then save.

import * as ImageManipulator from "expo-image-manipulator";
import { Dimensions, PixelRatio } from "react-native";
 
async function downsampleForDevice(localUri: string): Promise<string> {
  const { width } = Dimensions.get("screen");
  const scale = PixelRatio.get();
 
  // Use the device's physical pixels as the guide
  const targetWidth = Math.round(width * scale);
 
  const result = await ImageManipulator.manipulateAsync(
    localUri,
    [{ resize: { width: targetWidth } }], // height is computed from the aspect ratio
    { compress: 0.9, format: ImageManipulator.SaveFormat.JPEG }
  );
  return result.uri;
}

Here I multiply Dimensions.get("screen") by PixelRatio.get() to estimate physical pixels. I've personally done the yearly work of tracking new iPhone resolutions across several wallpaper apps, and optimizing the save size per device cuts the "it eats storage" complaints from space-conscious users. To avoid upscaling when the source is smaller than the screen, add a branch that skips the manipulate when the resize width would exceed the original width — that prevents blur.

Don't dead-end the user when permission is denied

Once canAskAgain is false — the user permanently denied — calling requestPermissionsAsync no matter how many times produces no dialog. If your app just says "please allow it" and stops there, the user has nowhere to tap and hits a dead end. You need a path straight to the Settings app.

import { Alert, Linking } from "react-native";
 
async function handleSavePress(remoteUrl: string) {
  const result = await saveRemoteImage(remoteUrl);
  if (result.ok) {
    // Quiet success feedback (a toast, etc.)
    return;
  }
 
  if (result.reason === "permission") {
    Alert.alert(
      "Saving to Photos isn't allowed",
      "Allow adding photos in Settings to enable saving.",
      [
        { text: "Later", style: "cancel" },
        { text: "Open Settings", onPress: () => Linking.openSettings() },
      ]
    );
    return;
  }
 
  if (result.reason === "download") {
    Alert.alert("Couldn't fetch the image", "Check your connection and try again.");
    return;
  }
 
  Alert.alert("Save failed", "Please wait a moment and try again.");
}

Linking.openSettings() opens the app's own settings screen. The key is varying the copy and next action per failure reason. Just routing permission to Settings and network to retry — same "failure," very different odds that the user recovers on their own. Splitting the reason into a type back in the save flow was precisely so this branch could be written directly.

A device verification matrix

This class of bug doesn't appear on a single device. At minimum, run the following combinations on a real device or simulator and you'll close out almost all of the "won't save" reviews.

What I learned running several apps in parallel is that the quality of a save feature is decided not by "speed on success" but by "not swallowing failures." If you monitor crash-free rates, check once whether you're swallowing exceptions around createAssetAsync — that is, whether failures are vanishing silently. Silent failures aren't counted as crashes, so they show up only in reviews.

For neighboring topics on permission-scope design, reading designing the right timing for the ATT permission dialog in a Rork app and fixing expo-image disk cache bloat in Rork together gives you the full picture of image-related permissions and storage.

As a first step, check whether your app's save flow is calling requestPermissionsAsync() without writeOnly — just that one line. If you only save yet request read + write together, adding true alone will lower your denial rate.