Images loaded from PHAsset, i.e. with ph:// uri, cause large memory leaks in New Architecture

[alexfoxy]

Description

Using the new architecture images loaded from a ph:// cause major memory leaks. Unlike images loaded via assets or a remote uri, images loads via ph:// uris seem to be loaded in to memory, but then not released when the image component is unmounted. This is not an issue on the old architecture.

I've tested on a real device and experience the same behaviour. I've also tested in Release to ensure it's not a dev/debug issue.

I have attached a video of the issue below, plus a video of the same app running with the new arch disabled which shows no memory leaks.

Steps to reproduce

1. Pull repo: https://github.com/alexfoxy/ImageMemoryTest
2. Follow usual RN setup, yarn, pod etc and run the project
3. Press "Use PH Image" button to load an image from your camera roll (it should be a high resolution image if possible)
4. Show & Hide the image using the buttons, you should notice memory increasing
5. Try the Asset Image & Remote Image for comparison which do not increase memory

React Native Version

0.79.2

Affected Platforms

Runtime - iOS

Output of npx @react-native-community/cli info

System:
  OS: macOS 15.1.1
  CPU: (10) arm64 Apple M2 Pro
  Memory: 208.94 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.13.0
    path: ~/.nvm/versions/node/v22.13.0/bin/node
  Yarn:
    version: 4.7.0
    path: ~/.nvm/versions/node/v22.13.0/bin/yarn
  npm:
    version: 10.9.2
    path: ~/.nvm/versions/node/v22.13.0/bin/npm
  Watchman:
    version: 2025.04.14.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.2
      - iOS 18.2
      - macOS 15.2
      - tvOS 18.2
      - visionOS 2.2
      - watchOS 11.2
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.19072.14.2412.12360217
  Xcode:
    version: 16.2/16C5032a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.9
    path: /usr/bin/javac
  Ruby:
    version: 3.4.3
    path: /opt/homebrew/opt/ruby/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 18.0.0
    wanted: 18.0.0
  react:
    installed: 19.0.0
    wanted: 19.0.0
  react-native:
    installed: 0.79.2
    wanted: 0.79.2
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

No stack trace or log

MANDATORY Reproducer

https://github.com/alexfoxy/ImageMemoryTest

Screenshots and Videos

I had to upload the videos to YouTube as they wouldn't attach here:
New Arch: https://www.youtube.com/watch?v=6U9QtshkRCs
Old Arch: https://www.youtube.com/watch?v=1C2xZEKFB24

[cipolleschi]

Hi @alexfoxy.
React native does not offer a way to load from ph:// out of the box, but relies on libraries to do so, for example @react-native-camera-roll/camera-roll that you installed in your reproducer. If there is a memory leak, this is happening in the library, not in React Native core. Can you first open an issue in the library repository?

If they then find that the problem is actually in RN core, we will investigate it, but we should first exclude that the problem is in the library.

Thank you so much.

[alexfoxy]

@cipolleschi

If RN does not support ph://, how does the <Image> component resolve the ph:// path to display the image?

[cipolleschi]

using a library: @react-native-camera-roll/camera-roll. This is present in your reproducer.
React native offers a hook for library to register themselves as handler of specific protocols, in this case the ph:// protocol.

So, when the app starts, the camera-roll library register itself. Whenever React Native finds a url that starts with ph:// it routes the url to the camera-roll library that knows how to handle the url properly.

[alexfoxy]

Got ya thanks. I have however noticed it's an issue with remote web images too, and I have managed to find the part of the RN code which is hanging on to the memory. I have created a new issue here with the findings: #51198