@react-native-community/blur: Native Blur and Vibrancy for React Native

What @react-native-community/blur actually wraps

React Native has no blur primitive. The platform views that produce a real blur are UIVisualEffectView on iOS and the Dimezis BlurView library on Android, and neither is reachable from JavaScript without a native module. This package is that bridge: a single BlurView component, plus a VibrancyView for iOS, that renders the native view and forwards a small set of props to it.

The audience is narrow and specific. You are building a React Native app, you want the frosted-glass treatment Apple uses for sheets and navigation bars, and you would rather not write the native module yourself. If your design calls for a Gaussian blur on an image, this is the wrong tool; a shader or an image-processing library handles that without a native view. This component blurs whatever is already rendered underneath it in the view hierarchy, which is a compositing operation, not an image filter.

Position in the tree decides what gets blurred

The mechanism is entirely about render order. The README's example puts an Image and a Text at absolute position covering the container, then places a BlurView with the same absolute style on top, then a final Text after it. The comment in the source is explicit: everything before the BlurView in terms of positioning and zIndex-ing will be blurred, and the trailing Text stays sharp because it renders on top of the blur.

That is the whole mental model. There is no blur radius applied to a target view; the BlurView is a translucent native layer that samples the composited pixels beneath it. It follows that you cannot blur a sibling that renders above it, and you cannot blur a view in a different subtree if the stacking order puts it later. It also means the cost is a compositing pass over the region the BlurView covers, so a full-screen BlurView is more expensive than a small one.

The prop surface splits by platform, and the split is not cosmetic. On iOS, blurType selects from the system effect names: xlight, light, dark, regular and prominent, plus the iOS 13 material family (chromeMaterial, material, thickMaterial, thinMaterial, ultraThinMaterial and their Dark and Light variants). On Android, blurType is not the whole story: blurRadius (0 to 25), downsampleFactor (0 to 25) and overlayColor exist only on Android, and their defaults are described as matching the iOS blurAmount. blurAmount runs 0 to 100 on both, but the README states the maximum on Android is 32 and higher values are clamped. Passing blurAmount={80} and expecting the same result on both platforms is a mistake the documentation warns about directly.

Installing it and getting a first blur on screen

The package is published as @react-native-community/blur. Installation is one JavaScript dependency plus a CocoaPods step on iOS. The README gives no Android-specific install step, which matches the repository layout: the android/ directory ships with the package.

yarn add @react-native-community/blur

Then, for iOS only:

cd ios && pod install

A first real use is the README's own example, trimmed to the parts that matter. The absolute style is what makes the blur cover the whole container, and the ordering is what selects the blurred content.

import { View, Image, Text, StyleSheet } from "react-native";
import { BlurView } from "@react-native-community/blur";

export default function Menu() {
  return (
    <View style={styles.container}>
      <Image source={{ uri }} style={styles.absolute} />
      <BlurView
        style={styles.absolute}
        blurType="light"
        blurAmount={10}
        reducedTransparencyFallbackColor="white"
      />
      <Text>I'm the non blurred text because I got rendered on top of the BlurView</Text>
    </View>
  );
}

With that mounted, the image is softened and the trailing text is not. If you flip the order, nothing blurs. The repository also ships an example app used to produce the README GIF, which you can bootstrap with the scripts in package.json: yarn bootstrap installs the example workspace, the root workspace and the example pods, and yarn example android/ios runs it. Running the example is the fastest way to see how the same props render on both platforms before you commit to a design.

VibrancyView is iOS only, and the README is blunt about it

VibrancyView takes the same props as BlurView (blurType, blurAmount, reducedTransparencyFallbackColor) and exists to let the content underneath a blurred surface show through more vividly. It is the effect behind Apple's translucent sidebars, where text sitting on the material picks up color from what is behind it.

Two constraints come with it. The README states plainly that VibrancyView is only supported on iOS, so any screen using it needs an Android branch. And it must contain nested views: the README notes that the VibrancyView must contain nested views, and its example nests a Text inside it inside an Image. A VibrancyView with no children renders nothing useful. If your UI is shared across platforms, this is the component that forces the first real platform fork in your styling code.

Where it breaks: Reduce Transparency, Android clamping and the missing web target

The accessibility path is the one that catches people out. When the iOS Reduce Transparency setting is enabled, the BlurView does not blur at all; it uses reducedTransparencyFallbackColor as its background color. If you do not provide that prop, the component picks a default fallback color: white, black or grey depending on blurType. That default may be perfectly reasonable, or it may be a grey rectangle where your design expected a dark panel. Either way, the prop is iOS only, so it does nothing on Android, and the README does not describe an equivalent Android behavior for the setting.

The second failure mode is silent clamping. On Android, blurAmount above 32 is clamped to 32. A design that specifies 50 will render as 32, and nothing in the component will tell you. Combined with the Android-only blurRadius, downsampleFactor and overlayColor props, the practical result is that "the same" blur is two different effects on two platforms, and tuning it means tuning each separately.

The third is scope. The repository contains android/, ios/, src/ and cpp/ entries, plus a react-native-blur.podspec. There is no web implementation in the package layout, so a React Native Web target gets nothing from this component. And because the blur samples already-rendered pixels, a BlurView placed over a video, a map or an animated list re-samples as those pixels change, which is a cost the README does not quantify.

Alternatives and how their approach differs

The search results around this package surface several other names, and the differences are structural rather than cosmetic. Expo BlurView comes from the Expo SDK: it is installed and versioned through Expo's package set rather than as a standalone community package, which means the upgrade path is tied to your Expo SDK version. If you are already on Expo, that coupling is a feature; if you are on bare React Native, it is an extra dependency layer.

Sbaiahmed1/react-native-blur and Danielsaraldi/react-native-blur-view are separate third-party implementations of the same idea. They are distinct packages with their own maintenance and their own prop surfaces, not forks you can swap in without reading their docs. Choosing between them and this one is a question of which prop set matches your design and which one you are willing to track.

react-native-blurhash solves a different problem entirely. BlurHash encodes a placeholder as a short string that decodes into a blurred preview, typically while a remote image loads. It produces a blur from data, not from the composited screen, so it works on web and does not need a native view. If your goal is a placeholder rather than a translucent surface, BlurHash is the closer fit and this package is not.

Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-05-09. The most recent tagged release is v4.4.1 from 2024-08-29, preceded by v4.4.0 in January 2024 and v4.3.2 in May 2023. The gap between the last release and the last push is worth noting: commits are landing on master, but they are not being cut into releases at the same cadence. Pin a version rather than tracking a branch if you need reproducibility.

The licence is MIT, declared in package.json and present as a LICENSE file at the repository root. MIT permits commercial use and modification with the copyright notice retained; this is a description of the licence text, not legal advice, and you should read LICENSE yourself if your organisation has specific requirements.

Upgrade cost concentrates in two places. Native dependency changes require a pod install on iOS, and the package ships android/, ios/ and cpp/ directories plus a podspec, so a version bump can touch the native build. Prop surface changes are the other: the iOS 13 material blurType values and the Android-only blurRadius, downsampleFactor and overlayColor props mean a design tuned against one version may need retuning after a bump. The example app in example/ is the practical way to check a new version against your own prop combinations before rolling it out.

Editorial conclusion

Adopt it if you need a native blur layer behind a modal, a tab bar or an overlay and you accept that iOS and Android render differently. Skip it if you need identical output across platforms, if you target web, or if you need a blur that follows animated content, since the component blurs what is already rendered beneath it. Verify three things before committing: that your React Native version matches the example app's dependencies, that your iOS minimum deployment target supports the blurType values you plan to use (the material and chromeMaterial families are iOS 13 only, and extraDark, regular and prominent are tvOS only), and that you pass reducedTransparencyFallbackColor so the Reduce Transparency accessibility setting does not fall back to a default you did not choose.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. margelo/react-native-blur on GitHub
4. README
5. Releases