Handling iOS Limited Photo Library Access in a Rork (Expo) App

Make the screen work from "only the selected photos"

Under limited access, getAssetsAsync returns only the photos the user selected. Accept that as the assumption, not a flaw, and design the screen to work from the selection. Ideally the same code runs for both full and limited.

// photos/usePhotos.ts
import { useCallback, useEffect, useState } from "react";
import * as MediaLibrary from "expo-media-library";
import { getPhotoAccess, PhotoAccess } from "./permission";
 
export function usePhotos() {
  const [access, setAccess] = useState<PhotoAccess>("denied");
  const [assets, setAssets] = useState<MediaLibrary.Asset[]>([]);
 
  const load = useCallback(async () => {
    const a = await getPhotoAccess();
    setAccess(a);
    if (a === "denied") {
      setAssets([]);
      return;
    }
    // Same call for full and limited. Under limited, only the chosen ones return
    const page = await MediaLibrary.getAssetsAsync({
      mediaType: "photo",
      sortBy: [["creationTime", false]],
      first: 200,
    });
    setAssets(page.assets);
  }, []);
 
  useEffect(() => { load(); }, [load]);
  return { access, assets, reload: load };
}

The screen varies what it shows by access. The important thing: when limited returns an empty assets, do not treat it as denied. Empty means nothing has been selected yet, so show an "add photos" path.

function PhotoGrid() {
  const { access, assets, reload } = usePhotos();
 
  if (access === "denied") {
    // Only truly denied goes to the Settings app
    return <DeniedView />;
  }
 
  return (
    <>
      {access === "limited" && (
        <LimitedBanner onAddMore={async () => {
          await presentLimitedPicker();
          await reload(); // reload after re-picking
        }} />
      )}
      {assets.length === 0 ? (
        <EmptySelectionView onPick={async () => {
          await presentLimitedPicker();
          await reload();
        }} />
      ) : (
        <Grid data={assets} />
      )}
    </>
  );
}

Offer "add more" under limited access

Give limited-access users a way to re-pick photos later. iOS has a mechanism to re-present the limited-library selection screen, callable from Expo via presentPermissionsPickerAsync.

// photos/presentLimitedPicker.ts
import * as MediaLibrary from "expo-media-library";
import { Platform } from "react-native";
 
export async function presentLimitedPicker(): Promise<void> {
  if (Platform.OS !== "ios") return; // this path is for iOS limited access
  // Show the screen to re-pick photos for the limited library
  if (typeof (MediaLibrary as any).presentPermissionsPickerAsync === "function") {
    await (MediaLibrary as any).presentPermissionsPickerAsync();
  }
}

The key is to always call reload() right after re-picking. iOS updates the accessible set the moment the picker closes, but the assets your app holds are stale. Skip the reload and the photos the user just added don't appear, making the feature feel "broken."

Also, prompting to add photos on every launch is annoying and runs against the wishes of a user who chose limited access. A modest, always-present banner, with the picker shown only when they actively tap "add photos," strikes the right distance.

Rollout steps

When retrofitting this into existing photo features, this order is safe. I followed it myself when adding "use your own photo as a background" to my indie wallpaper app.

1. Centralize permission acquisition in requestPhotoAccess, returning the three states all / limited / denied.
2. Replace loading with usePhotos, rebuilding the screen around the assumption that limited access returns only the chosen photos. Confirm that limited plus empty is not treated as denied.
3. Show the "add photos" path (presentLimitedPicker then reload) only under limited access, and verify on a real device that re-picks are reflected.

This way you can verify behavior at each step and avoid the pitfall of mistaking limited access for denial. Photo handling is scrutinized in App Store privacy review, and as with ad SDKs like AdMob, careful permission handling pays off in your rating.

Pitfalls and notes from production

A few things from doing this for real. First, if you develop with full access on your test device, you basically never reproduce this. I didn't at first either. Limited access doesn't switch back until you explicitly set it to "Select Photos" again in the Settings app, so during testing you must deliberately set it to limited and verify. Just making that a habit kills bugs like the reported one before shipping.

Second, the wording. A one-size message — "please grant access" — rings off-target for a limited-access user. I changed the limited-access banner to a state-aware note: "Only the photos you chose are available. Tap 'Add Photos' to include more." When users understand the result of their own choice, dissatisfaction is less likely to turn into a support ticket.

Finally, a privacy-respecting design comes back as trust over the long run. A user who goes out of their way to choose limited access watches how the app behaves. Honor that choice and create a state where "it feels good with just what I picked," and reviews receive it warmly. Permissions are an unglamorous area, but the more carefully you face them, the more it pays off.

The crux of photo permission is not to think in a granted binary. Put the three states — full, limited, denied — in your assumptions from the start, and limited access stops being an exception and becomes an ordinary option you handle gracefully.