react-native-fast-image: the fork built for the New Architecture

A fork whose whole purpose is keeping up

The first line of the README carries a warning that is really the thesis of the project, that this is a fork of react-native-fast-image and all credit goes to the original author. The fork exists because the original package and the platform it targeted had drifted apart, and the header states the difference plainly, that FastImage is a high performance image component for React Native, now fully optimized for the New React Native Architecture. The new features list names three things: TurboModules and Fabric Renderer compatibility for enhanced performance, AVIF image support for next generation image formats, and numerous bug fixes and performance improvements over the original repository. The two compatibility items carry version floors, with Fabric Renderer support from v8.7.0 and TurboModules support from v8.8.0, which tells you the fork was not born with the new architecture but grew into it, adding the pieces release by release. The package is published under a different scope, @d11/react-native-fast-image, and the author is DreamHorizon, with the repository under the dream-horizon-org organisation, so this is a maintained fork with its own release line rather than a community patch.

The problems it solves are cache problems, not decode problems

FastImage is described as a drop-in replacement for React Native's Image component, and the problems it lists are worth reading because they are all symptoms of the same root cause. Flickering during loading, cache inconsistencies, slow loading from cache, and overall suboptimal performance. Each of those comes from React Native's own image pipeline not controlling the cache, so a component that wants to know whether a given URL is already on disk has no way to ask. The mechanism FastImage uses is delegation to the platform's best image library, SDWebImage on iOS and Glide on Android, for native caching and high efficiency. That is the important architectural fact about the component, because it means the caching semantics you get are the semantics of those two libraries rather than something the component defines. A URL that Glide has cached is served from Glide's cache, with Glide's disk policy, its own resize strategy and its own notion of memory pressure. The component is a React Native surface over two mature native caching stacks, which is why it behaves consistently on both platforms and why the documentation has to talk about Glide configuration at all.

The feature list is short and each item maps to a native capability

The features list is compact, and reading it tells you what the component can and cannot do. Aggressive caching for high speed is the core. Customizable authorization headers matter more than they sound, because the built-in Image component cannot attach a bearer token to an image request, and any image behind an authenticated endpoint is otherwise unrenderable. Priority-based image loading lets you say which image matters on the current screen, so the hero image is fetched before the thumbnail further down the list. Preloading for instant display covers the case where you know the next screen's image before the user navigates. Full GIF, SVG and AVIF support means animated GIFs and vector artwork work through the same component, and AVIF is the addition specific to this fork. Support for borderRadius is listed separately, which is a hint that clipping a cached image is not a given. The interesting absence is any mention of a custom cache directory, cache size or eviction policy. Those are the knobs you would want, and they are not in the list, which is consistent with the delegation model described earlier. Anything you want to change about caching behaviour is a Glide or SDWebImage configuration, and the repository has a separate guide for the case where you already use Glide with an AppGlideModule, which is the situation where integration goes wrong.

Installing it, the SVG opt-out and the pod step

Installation is a package manager command plus the iOS pod step, and the package name is the scoped one.

yarn add @d11/react-native-fast-image
cd ios && pod install

The npm route is the same shape.

npm install @d11/react-native-fast-image
cd ios && pod install

The README also states the floor, that you must be using React Native 0.60.0 or higher to use the most recent version. There is an optional switch that is worth knowing about even if you plan to use SVG, because it shows how the native dependency surface is managed. If you do not need SVG support you can disable the SVG decoders via an environment variable to reduce native dependencies and binary size. On iOS you set it before running CocoaPods, and on Android before building.

export DISABLE_SVG=1
cd ios && pod install

export DISABLE_SVG=1
# then build as usual, e.g.
yarn android

To re-enable SVG support you unset the variable or set it to 0 and reinstall the pods or rebuild. The ordering constraint is real on both platforms, since the variable is read at install or build time, so changing it later requires a repeat of the step that follows it. That is a mild annoyance, but it buys a smaller binary and fewer native dependencies, and for a mobile app where download size matters, that trade is often worth making.

The API surface, and what cacheControl actually controls

The property table is where the component's real behaviour is documented, and one row deserves attention. The source property accepts an object with sub-properties for uri, headers, priority and cache, and the priority values are low, normal as the default, and high. The resizeMode values are contain, cover as the default, stretch and center. The transition values begin with none as the default. The row that matters most is source.cache, which takes a FastImage.cacheControl value, and the three options are immutable as the default, web and cacheOnly. Those names describe the caching contract with the origin server rather than the local disk cache. Immutable tells the origin and the cache that the URL will never serve different bytes, which is the right setting for content-addressed or versioned URLs and the wrong one for a URL whose contents change. Web is for ordinary resources that may be revalidated. CacheOnly says use whatever is already cached and never hit the network, which is what you want for a screen that must render instantly from what you know is there. The default of immutable is a performance choice that quietly assumes your URLs are stable, and if they are not, the symptom is a stale image that no amount of clearing the app cache will fix until the URL changes. The defaultSource property has a platform caveat worth reading, since on Android defaultSource does not work in debug mode.

ProGuard rules and the Android build, plus the release process

If you shrink your Android build with ProGuard, the README asks you to add rules to android/app/proguard-rules.pro, and the rules themselves are the useful part because they name the two things that get broken.

-keep public class com.dylanvann.fastimage.* {*;}
-keep public class * implements com.bumptech.glide.module.GlideModule
-keep public class * extends com.bumptech.glide.module.AppGlideModule
-keep public enum com.bumptech.glide.load.ImageHeaderParser$** {
  **[] $VALUES;
  public *;
}

The keep rules for the original package name are the confirmation that this is a fork and not a rewrite, since the native class names still carry the com.dylanvann.fastimage prefix, and the GlideModule and AppGlideModule rules exist because Glide discovers those implementations reflectively. The final entry matters for the same reason, since the enum rule protects the values array of the image header parser, a class that is only ever reached by reflection and therefore vanishes when the shrinker cannot see it. On the packaging side, the npm package is dual licensed as MIT AND Apache-2.0, which is the usual combination when a project carries both its own code and vendored native code with different terms. The repository also contains an example app and an example server, a jest setup, a publish-nightly script for a nightly channel, and release-it configuration with a changelog generated by auto-changelog. The release list shows v8.13.0 from 2025-11-05, v8.12.0 from 2025-09-05 and v8.11.1 from 2025-08-18, and the last push to the repository was on 2026-04-06, so the release line is moving but not quickly.

Editorial conclusion

Adopt @d11/react-native-fast-image if you are on the New React Native Architecture, need GIF, SVG or AVIF support in a single image component, and want the caching behaviour that SDWebImage and Glide provide without writing the native layer yourself. Skip it if you are still on the old architecture, where the original package may serve you, or if you have no custom authorisation headers and no animated image requirements, since a plain Image with a caching policy would do. Verify first that your React Native version is 0.60.0 or higher, that your existing Glide setup does not already have an AppGlideModule conflict, and that you read the ProGuard rules if you shrink your Android build.

Frequently asked questions

Official sources

1. dream-horizon-org/react-native-fast-image on GitHub
2. Issues
3. License: MIT
4. README
5. Releases