react-native-video: v6 stays, v7 needs Nitro, and two features are still TODO

Two rows in the feature table are not finished

The feature table has a status column, and reading it is the fastest way to know whether this fits.

Marked available: playing all video formats natively supported by iOS and Android, local and remote playback, HLS, DASH and SmoothStreaming streaming, Expo plugin support, offline playback with download and side-tracks and side-captions through an optional SDK, Picture in Picture, advanced control over playback and buffering, Widevine and FairPlay DRM, and basic Web support.

Marked as in development: fine-grained control over tracks, buffering and events. That is the row to notice, because it is the one a developer reaches for when building a custom scrubber or an analytics pipeline.

Marked TODO with an issue link: TV support, issue 4607, and VisionOS support, issue 4608.

So the honest summary is a strong mobile component with two platforms absent and one control surface unfinished, which the table states rather than hides.

The offline row carries its own dependency: offline playback, video download, side-tracks and side-captions come via an optional SDK linked from the documentation, so that capability is a separate purchase or a separate integration rather than something in the package.

v5 is end-of-life, v6 is maintained, v7 is a rewrite

The Project Status table maps each line to an architecture, and that mapping is the migration story.

v5 and lower: end-of-life, with commercial support available, on the old architecture.

v6: maintained by the community together with the maintainers' company, on old plus new through an interop layer.

v7: active development, with full support for the old and new architectures.

And v7 introduces full support for the new React Native architecture, which the README describes as unlocking better performance, improved consistency and modern native modules.

In other words, v6 reaches the new architecture through an interop layer, while v7 is listed with full support for both architectures.

The releases show both lines moving: v7.0.0-beta.12 on 2026-10-06, v6.19.3 on 2026-09-18 and v7.0.0-beta.11 on 2026-08-12. So v6 is not abandoned and v7 is not done.

v7 needs react-native-nitro-modules before it needs react-native-video

The Requirements section lists React Native 0.75 or higher, and `react-native-nitro-modules` at 0.31.10 or higher with a link to the nitro requirements.

The install order matters, because the nitro module comes first:

npm install react-native-nitro-modules

then the player itself, from the beta tag, and the CocoaPods step:

# Install the beta version of react-native-video v7
npm install react-native-video@beta

# Install pods
cd ios && pod install

So v7 adds a native dependency rather than bundling what it needs, and the beta tag is how you install it.

There is also a warning for older React Native. Below 0.80 there is a bug that prevents errors from being handled properly by nitro modules on Android, and the project recommends applying a patch for `react-native-nitro-modules` with patch-package. Without it you will not be able to recognise errors, and all of them will be thrown as unknown errors.

That is a specific failure with a specific cause and a specific fix, which is more useful than a vague compatibility note.

The API is a hook that returns a player and a view that takes it

The usage example uses two imports.

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
  />
);

So the player is created by a hook with the source and an initialiser callback that receives the player, and the view is a separate component that takes the player as a prop plus a style and a `controls` flag.

The split matters for composition. The player is created separately and passed to the view as a prop. The `controls` prop is a boolean on the view rather than a mode on the player.

The v7 documentation is linked separately from the general documentation, which is how a component with two live major lines keeps its examples unambiguous.

The build is a Bun workspace of five members with patches applied on install

The root manifest is where the monorepo shape is visible.

It is named `react-native-video-monorepo`, marked private, pinned to bun 1.3.1 as its package manager, and its workspaces are `packages/react-native-video`, `packages/drm-plugin`, `example`, `test-app` and `docs`.

So DRM is its own package rather than a folder inside the player, and there are two apps: `example` for the public example and `test-app` for the test suite.

The scripts are Bun filters. `build`, `specs`, `lint` and `typecheck` all run across the workspace with a filter, and each workspace has a shortcut that runs in its own directory, so `drm-plugin` or `example` can be driven without the root. Tests are `bun test e2e scripts test-app packages/react-native-video/__tests__`, which spans the end-to-end directory, the scripts, the test app and the unit tests in one invocation.

One line is worth reading twice: `postinstall` runs `patch-package` for both `example/patches` and `test-app/patches`. So the example and the test app are kept working by patches applied at install time.

The commercial gap is the reason three paid plugins exist

The README has a section explaining that the maintainers see a gap between open source and commercial players and want to fill it with plugins, and it asks a direct question: are you using a commercial player just for one or two features, and might you be paying for a licence to get caching, ads or analytics?

Three plugins are listed as already available.

Offline Video covers the logic for downloading HLS and DASH streams and standard video files to enable offline playback. Background Uploader handles uploads even when the app is minimised, which the README notes is not strictly a player plugin but is useful anyway. And Chapter Markers put visual markers on the timeline to navigate content.

Then the commercial table: professional support packages with priority bug fixes, guaranteed SLAs and roadmap influence; an issue booster on a pay-per-issue model; the offline video SDK as a plug-and-play secure download solution for iOS and Android; integration support for video, DRM and offline; a free DRM token generator for Widevine and FairPlay testing; and ready boilerplates.

So the open source component is the player, and the commercial layer is the set of things a product needs around it. That division is stated rather than implied, which makes it possible to decide which half you actually need.

Editorial conclusion

react-native-video suits a React Native app on 0.75 or newer that needs DRM, offline playback and streaming on iOS and Android, and that can accept a second native dependency. It does not suit you if you need TV or VisionOS support today, or if you need fine-grained track and buffering control, all of which the table marks unfinished or TODO. Verify three things before you upgrade: that you are choosing v6 or v7 deliberately, since v5 is end-of-life and v6 still receives maintenance, that your React Native is 0.80 or newer unless you are willing to apply the documented patch-package fix for older versions, and that `react-native-nitro-modules` at 0.31.10 or higher is acceptable in your dependency tree, since v7 requires it rather than bundling it.

Frequently asked questions

Official sources

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