react-native-video v7: What the Nitro Rewrite Changes for React Native Video Playback

The gap react-native-video fills in a React Native app

React Native ships no video component. The platform views exist on iOS and Android, but nothing in the core bridges them, so playback, buffering state, track selection and fullscreen handling all have to come from somewhere. react-native-video is that somewhere: a single component plus a player object that wraps the native players on each platform and exposes them through one JavaScript surface. The README describes it as "the most battle-tested open-source video player component for React Native" and lists DRM, offline playback and HLS/DASH streaming as the headline capabilities.

The audience is narrow and specific. You need it if you are shipping a React Native app where video is a first-class feature rather than an embedded web view: a streaming catalogue, a course player, a feed with autoplay. If your video is a single MP4 in a marketing screen, a WebView or a platform-specific native module may be less machinery than you need. The project also carries a commercial layer from TheWidlarzGroup, with paid support packages, an issue booster, and an offline video SDK, so the open source component sits inside a business that sells the pieces the component leaves out.

How v7 works: Nitro Modules, a player object, and a view

The v7 API splits playback state from rendering. useVideoPlayer takes a source and a setup callback and returns a player handle; VideoView receives that handle and draws the surface. The callback is where you configure the player before it renders, which is why autoplay in the README example is a single _player.play() call rather than a prop.

Underneath, the native binding is built on react-native-nitro-modules. The README states the requirement plainly: react-native-nitro-modules >=0.31.10, and React Native 0.75 or higher. That dependency is the architectural change in v7. The project status table lists v6 as "Old + New (Interop Layer)" and v7 as "Old + New (Full Support)", so v7 is the version where the New Architecture is handled natively rather than through the interop shim. The repository is a monorepo with workspaces for packages/react-native-video, packages/drm-plugin, example, test-app and docs, which is why the root package.json is named react-native-video-monorepo and marked private.

One documented sharp edge: for React Native below 0.80, the README says there is a bug that prevents nitro modules from handling errors properly on Android, and that without the suggested patch-package patch "all will be thrown as unknown errors". That is a real debugging cost, not a cosmetic one.

Installing react-native-video v7 and rendering a first video

The README requires react-native-nitro-modules first, then the beta of react-native-video. Both commands are run from your app project, not from a checkout of the repository.

npm install react-native-nitro-modules
npm install react-native-video@beta
cd ios && pod install

After pod install completes, the native module is linked. On Android the autolinking step picks up the package during the next build; the README does not list extra Android steps beyond the patch note for React Native below 0.80.

The README's usage example is the shortest path to a working screen. It imports useVideoPlayer and VideoView, plays a remote MP4 on mount, and gives the view a 16:9 box with native controls enabled.

import { useVideoPlayer, VideoView } from 'react-native-video';

export default () => (
  const player = useVideoPlayer(
    'https://www.w3schools.com/html/mov_bbb.mp4',
    (_player) => {
      _player.play();
    }
  );

  <VideoView
    player={player}
    style={{ width: '100%', aspectRatio: 16 / 9 }}
    controls
  />
);

What you should see is the Big Buck Bunny sample playing in a full-width box with the platform's own controls overlaid. If you get a blank surface instead, the first thing to check is whether react-native-nitro-modules resolved at the version the README requires, since the player cannot be constructed without it.

The repository also ships an AI agent skill under skills/react-native-video, which the README says is installed with npx skills add TheWidlarzGroup/react-native-video for use with coding agents. Treat that as a documentation aid, not a substitute for reading the v7 docs at docs.thewidlarzgroup.com.

The beta label is not decoration

The README opens with a warning block: v7 is in active development, and you "can expect breaking changes and missing features". The version numbers back that up. The most recent stable-tagged release is v6.19.3, while v7 is published through beta tags such as 7.0.0-beta.11. That means npm install react-native-video@beta, as the README instructs, is the intended install path for v7, and it is not the same as installing a stable release.

The feature table has its own gaps. Fine-grained control over tracks, buffering and events is marked "In Development" rather than available. TV support and VisionOS support are both listed as TODO with links to open issues. Web support is described as basic. If your product needs Android TV, tvOS or a Vision Pro target, the README is telling you those are not there yet, and no amount of configuration will change that.

Offline playback deserves a closer read. The feature table marks it available, but the row itself points to an "optional SDK" and the services section sells it as the Offline Video SDK. So the download-and-play-later path is a commercial add-on, not something you get from the npm package. The same pattern applies to chapter markers and the background uploader: they are listed as existing products, not as part of the open source component. That is a legitimate business model, but it means an evaluation that only reads the feature table can come away with the wrong expectation.

v6 against v7, and where expo-video fits

The status table gives you three tiers. v5 and lower is end-of-life with commercial support offered. v6 is "Maintained (community + TWG)" and runs on the Old Architecture plus the New Architecture interop layer. v7 is active development with full New Architecture support. The practical difference is not a feature list; it is which architecture your app is on and how much churn you can absorb. A team on the Old Architecture that is not migrating soon has little reason to take on the Nitro dependency and the beta tag simultaneously.

Against expo-video, the split is about scope and control. expo-video is the Expo-managed player, which fits naturally when your app already runs on Expo's module system and you want playback to behave like every other Expo module. react-native-video is the bare React Native path, and the README lists Expo plugin support as available, so it does work inside Expo projects. The reason to pick react-native-video over expo-video is the surface area: DRM with Widevine and FairPlay, HLS, DASH and SmoothStreaming, and the track and buffering controls the project exposes. The reason to pick expo-video is that you do not want to manage react-native-nitro-modules and pod install yourself. Neither is wrong; they optimize for different teams.

Maintenance, licensing, and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-21, one day before the date used for this assessment, with v6.19.3 released on 2026-09-18. Both the v6 line and the v7 beta line are receiving work. The README's own status table calls v6 maintained by the community and TheWidlarzGroup, and v7 in active development.

The licence is MIT, which is permissive and places no conditions on commercial use beyond keeping the notice. The commercial offerings in the README (support packages, the offline SDK, the DRM token generator) are separate products under their own terms; nothing in the README suggests the MIT grant extends to them. That is a distinction worth confirming with your own legal review rather than inferring from the repository licence file.

Upgrade cost is the part teams underestimate. Moving from v6 to v7 is not a version bump: the API in the README is hook-based, useVideoPlayer plus VideoView, and the README warns of breaking changes. You also inherit a new native dependency and the React Native 0.75 floor. On the build side, the monorepo uses bun as its package manager and patch-package for example and test-app patches, which matters if you plan to run the example app or contribute rather than just consume the package.

Editorial conclusion

Adopt react-native-video v7 if you are already on React Native 0.75 or higher and can accept beta churn, and stay on v6 if you need the Old Architecture interop path or you cannot add react-native-nitro-modules. Before committing, verify three things yourself: that your React Native version satisfies the 0.75 minimum, that pod install completes after adding both packages, and that your target platforms are covered, since TV and VisionOS are listed as TODO in the README. The project's own status table is the honest signal here: v7 is active development, not a finished release, and the v7 README warns of breaking changes and missing features.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TheWidlarzGroup/react-native-video on GitHub