[isaaclins]

Summary:

Fixes #12220.

Bundled images (require('./photo.jpg')) are loaded on iOS through +[UIImage imageNamed:]. UIKit keeps every image loaded that way in its own cache: after the <Image> changes source or unmounts, the decoded bitmap stays in memory. Slideshows, onboarding flows or image sequences with many large local images grow until the app is killed.

Reproduced on 0.88.0 (Release, iOS 27.1 simulator): 20 local 3000x4000 JPEGs shown one after another, then the <Image> unmounted.

	while cycling	after unmount
today	grows ~46 MB per image, 935 MB	935 MB
with cache: 'reload' (this PR)	60–110 MB	17 MB

Two simulated memory warnings while the 935 MB were held freed nothing (the app logged Received memory warning), so this isn't a cache that empties itself under pressure.

RN's own RCTImageCache can't replace the system cache here: the bundle asset loaders opt out of it (shouldCacheLoadedImages returns NO), and it only stores images decoded from data. So simply dropping imageNamed: for everyone would leave small bundled icons uncached. Following the discussion in the issue (no heuristics, let the developer choose per source), this PR makes the existing cache: 'reload' option ("no existing cache data should be used") apply to bundled images too:

• RCTImageURLLoader gets an optional loadImageIgnoringCacheForURL:… method. RCTImageLoader calls it when the request's cache policy is NSURLRequestReloadIgnoringLocalCacheData and the loader implements it; otherwise nothing changes.
• RCTBundleAssetImageLoader and RCTLocalAssetImageLoader implement it with the new RCTImageFromLocalAssetURLIgnoringSystemCache, which reads the file with imageWithContentsOfFile: instead of imageNamed: (the existing file-system fallback). Images compiled into an asset catalog can only be loaded by name and still go through the system cache.
• Default behavior is unchanged.

Usage:

<Image source={{...Image.resolveAssetSource(require('./slide.jpg')), cache: 'reload'}} />

Changelog:

[IOS] [FIXED] - Bundled images with cache: 'reload' are no longer kept in the system image cache after they stop being shown

Test Plan:

Test app: RN 0.88.0, Release build, iOS 27.1 simulator, patched React Native built from source. 20 local 3000x4000 JPEGs, each shown for 1 s, then the <Image> unmounted; app footprint sampled every second with footprint.

• Without cache: identical to before the change (grows to 935 MB, stays after unmount).
• With cache: 'reload': 60–110 MB while cycling, 17 MB after unmount.
• Screenshots at image 8, image 19 and after unmount look identical in both modes.

[javache]

I'd really have assumed that the UIImage internal image cache responds to memory warnings. Bypassing it just for the sake of showing a smaller memory footprint, while making UX worse is making worse optimization trade-off.

Is there external evidence for this?

[isaaclins]

Fair question. What I have is from the simulator only: with 20 bundled 3000x4000 JPEGs shown one after another and then the <Image> unmounted, the app stayed at ~935 MB, and two memory warnings sent through the simulator (the app logged Received memory warning) didn't free any of it. With imageNamed: skipped it dropped to 17 MB, so nothing in RN itself is holding on to them.

That doesn't show the cache won't drain under real memory pressure on a device, which is what actually matters. I'll run the same test on a physical device and report back whether the cache drains or the app gets killed. If it drains, this isn't needed and I'll close it.

On the UX side: the default path is unchanged. Bundled images only skip the system cache when the source sets cache: 'reload'.