react-native: Assets uri's that begin with ph:// cause error

@norbusonam @mrousavy @tsapeta I spin up an app with 0.71.1, and the Old Architecture fails in the same way as the new one.

Repro:

npx react-native@0.71.1 init TestImage71_1 --version 0.71.1 #this installs pods for the old arch by default.
cd TestImage71_1/ios
open TestImage71_1.xcworkspace
cd ..
yarn start

I retrieved the ID by:

1. Adding the NSPhotoLibraryUsageDescription in the capabilities in Xcode
2. Adding the Photos framework in the Frameworks, Libraries and Embedded Contents in the General tab of the project in Xcode
3. Adding this code to the app delegate to read the id:

#import <Photos/PHAsset.h>
//...
PHFetchResult<PHAsset *> * res = [PHAsset fetchAssetsWithOptions:nil];
PHAsset * first = res.firstObject;
NSLog(@"Id: %@", first.localIdentifier);

Then, replace the App.tsx content with the following:

import React from 'react';
import {
  SafeAreaView,
  ScrollView,
  StatusBar,
  useColorScheme,
  Image,
  View,
} from 'react-native';

import {Colors} from 'react-native/Libraries/NewAppScreen';

function App(): JSX.Element {
  const isDarkMode = useColorScheme() === 'dark';

  const backgroundStyle = {
    backgroundColor: isDarkMode ? Colors.darker : Colors.lighter,
  };

  return (
    <SafeAreaView style={backgroundStyle}>
      <StatusBar
        barStyle={isDarkMode ? 'light-content' : 'dark-content'}
        backgroundColor={backgroundStyle.backgroundColor}
      />
      <ScrollView
        contentInsetAdjustmentBehavior="automatic"
        style={backgroundStyle}>
        <View
          style={{
            backgroundColor: isDarkMode ? Colors.black : Colors.white,
          }}>
          <Image
            source={{uri: 'ph://106E99A1-4F6A-45A2-B320-B0AD4A8E8473'}}
            style={{width: 100, height: 100}}
          />
        </View>
      </ScrollView>
    </SafeAreaView>
  );
}

export default App;

For my simulator, 106E99A1-4F6A-45A2-B320-B0AD4A8E8473 is a valid id for an asset in the camera roll.

When I run the app in the Old Architecture, I get the same error message:

Could it be that, in the Old Architecture, the libraries were able to self register their image handler in the list of handlers? So, what I think was happening:

1. yarn add react-native-cameraroll #and example of library that can handle ph:// url schemas
2. Add NSPhotoLibraryUsageDescription
3. Use `<Image source:{{ uri: “ph://*” }} />

And it looked like React Native is able to manage the ph:// directly, but it was actually a library handling that?

That fits with my understanding and as a difference between New/Old Arch. In fact, libraries couldn’t, before 0.74, register themselves as URL Handlers/Image Loaders in the New Architecture.

up, we don’t want for this issue to be reaped. We will work on this next half.

Closing this as it is an intended React Native behaviour.

The Old Architecture is relying on some library to pick up the ph:// protocol. Libraries on the Old Architecture can register automatically to respond to custom URL protocols, that’s why it looked like React Native was able to load images using the ph:// protocol.

In the New Architecture, before 0.74, libraries could not register themselves as URL handler, hence, this issue has been opened. In 0.74, thanks to this PR, libraries can now register themselves as URL handler, filling the gap between the Old and the New architecture.

Sharing some findings and a solution that worked for me:

Findings

According to this issue React Native no longer support’s ph:// routes after @react-native-camera-roll/camera-roll was separated, and installing @react-native-camera-roll/camera-roll should integrate the proper handler. However, according to this issue the new architecture hard codes RCTURLRequestHandler, which means simply installing @react-native-camera-roll/camera-roll won’t be enough to solve the problem.

Solution

Ultimetly, I was able to work around this by:

1. install @react-native-camera-roll/camera-roll
2. Override getModuleInstanceFromClass in your AppDelegate.mm to use @react-native-camera-roll/camera-roll’s RNCAssetsLibraryRequestHandler handler:

...

#import "RNCAssetsLibraryRequestHandler.h"
#import <React/RCTImageLoader.h>
#import <React/RCTDataRequestHandler.h>
#import <React/RCTFileRequestHandler.h>
#import <React/RCTGIFImageDecoder.h>
#import <React/RCTHTTPRequestHandler.h>
#import <React/RCTLocalAssetImageLoader.h>
#import <React/RCTNetworking.h>

...

- (id<RCTTurboModule>)getModuleInstanceFromClass:(Class)moduleClass
{
  // Set up the default RCTImageLoader and RCTNetworking modules.
  if (moduleClass == RCTImageLoader.class) {
    return [[moduleClass alloc] initWithRedirectDelegate:nil
        loadersProvider:^NSArray<id<RCTImageURLLoader>> *(RCTModuleRegistry *) {
          return @[ [RCTLocalAssetImageLoader new] ];
        }
        decodersProvider:^NSArray<id<RCTImageDataDecoder>> *(RCTModuleRegistry *) {
          return @[ [RCTGIFImageDecoder new] ];
        }];
  } else if (moduleClass == RCTNetworking.class) {
    return [[moduleClass alloc] initWithHandlersProvider:^NSArray<id<RCTURLRequestHandler>> *(RCTModuleRegistry *) {
      return @[
        [RCTHTTPRequestHandler new],
        [RCTDataRequestHandler new],
        [RCTFileRequestHandler new],
        [RNCAssetsLibraryRequestHandler new],
      ];
    }];
  }
  // No custom initializer here.
  return [moduleClass new];
}

...

Extra Info

After these finding’s I realized the reason ph:// routes were working on the old architecture was likely because expo provides a EXImageLoader. And since the new architecture hardcodes RCTURLRequestHandler, it did now work there.

Hi @norbusonam, thank you for opening the issue and to explore it further. We are aware of this limitation for the new Architecture, unfortunately. I see you found the PR trying to fix that, but we are not convinced by that fix yet.

Your override is a good workaround for the time being, while we find a better solution.

What does the ph:// prefix mean? What kind of permissions does the user need to grant?

Just mean that the URI starts with ph://. These URI’s route to PHAssets in iOS (basically just photo library assets).

That issue with permissions was just an expo-image thing.

The problem here is that React Native’s core Image component errors when it tries to render any image with a ph:// on the new architecture. I confirmed this was a regression from the old architecture.

EDIT: To clarify, the user does need to grant either limited or full access to photo library to render a photo library image, but that is not the main issue here

please save me!!!

In my scenario, I used expo-media-library to retrieve the uri’s. I built my app with the old architecture, and this error did not persist.

As this is related to expo-media-library (which lives here https://github.com/expo/expo/tree/main/packages/expo-media-library) and their support for New Architecture, you should open this issue against Expo’s repo.