8 React Native Video Editor Options and the Code You Inherit

TL;DR

• In React Native the editing runs in native code, so what you pick is the bridge layer.
• Four of the eight publish a current React Native package. Only two of those declare a codegen spec, and one of the three without a spec shipped this month.
• Two never run on the device: both render on a server, and the one browser preview among them is desktop-only.
• FFmpegKit is retired. Repository archived 2 July 2026, last React Native release September 2023.
• Package-and-docs screen, no device runs.

If you are picking a React Native video editor, start with the layer you will actually own: the JavaScript package and its native bridge.

Read who publishes it, under which license, whether it declares a codegen spec, when it last shipped, and where the editing work runs. Those five answers narrow the field faster than any feature list.

This is the screening pass. I read packages and documentation to decide which options are worth putting on a device at all. The device measurements, with real export runs, come in a later post.

Where these facts come from

I went through the npm metadata for each package: the license field, the codegenConfig block, the published date, and the peer and dev dependency pins. Then each project's own documentation. Everything below was read in October 2026 unless a sentence says otherwise.

You can redo the package half of this in one line, which is the whole reason the screen is built on metadata rather than on feature lists:

npm view react-native-video-trim version license time.modified codegenConfig

That prints checks 1, 2, and 3 for any package in this post, and for any package that gets published after it. The numbers below will age. The command will not.

Nothing here was installed or run. I did no exports, and I timed nothing, so there is no device, no OS version, no chipset, and no per-device result anywhere in this post.

Export timings for these SDKs do exist, published as benchmarks by the companies selling them. I produced none of them.

For anything that is not on npm, the vendor documentation is the source, and a documentation page is a snapshot of whenever someone last looked. Before any of it decides a build, get the claim from the vendor in a document with a date and a name on it.

Check 1: Who publishes the React Native package, and what license does it carry?

Look at the npm author field, the maintainer list, and the license field.

An author that is a company means a support contract is possible and a bill is coming. A single named maintainer means your escalation path is one person's inbox.

IMG.LY publishes @imgly/editor-react-native under the author "IMG.LY GmbH", maintained by company accounts rather than one individual. Its license field reads "SEE LICENSE IN LICENSE.md", which is a commercial license. That is a complete first-party React Native story: the vendor writes the bridge and signs for it.

Licensing is per target platform for React Native or Flutter, monthly or yearly, with one license covering several app identifiers such as staging, beta, and production, as IMG.LY's video SDK page and its pricing page read. Access is commercial and sales-led, full white-labeling is offered, and enterprise terms include an air-gapped option.

Those two pages are the one exception to the October reading above. I last went through them in June, so of everything here, they are the most likely to have moved.

Banuba publishes video-editor-react-native, authored by Banuba, against the repository at GitHub, with one company maintainer account.

Its npm license field reads MIT, and that one needs reading slowly. The SDK is commercial and will not initialise without a token, so the MIT covers the bridge code in the package and not the engine underneath it. IMG.LY's field says "SEE LICENSE IN LICENSE.md" and tells you that in the field itself. If you run check 1 the way I just described it, on this listing you get the wrong answer.

react-native-video-trim is MIT, authored by Duc Trung Mai, with one maintainer on the package.

MIT is the cleanest license outcome in this set: no per-platform fee, no approval gate, and the whole module is small enough to read end to end, since its repository scopes itself as "Video trimmer for your React Native app".

react-native-video-processing is also MIT, authored by Shahen Hovhannisyan, one maintainer, described as "Native Video processing/editing for React-Native" on its repository. MIT plus a dormant codebase means you own the fork outright, with no license conversation to have.

FFmpegKit's React Native library is LGPL v3.0 by default, and GPL v3.0 when the build enables GPL-licensed libraries, through the --enable-gpl flag or a prebuilt package with a -gpl suffix, as its repository documents.

Its own patents section states the belief that FFmpeg, kvazaar, x264 and x265 include algorithms subject to software patents, and recommends legal advice. It also gives format coverage no vendor SDK in this group matches, with no license fee attached.

Shotstack's Studio SDK is published as @shotstack/shotstack-studio under PolyForm Shield 1.0.0, which Shotstack describes as usable "for any application, commercial or non-commercial, as long as it doesn't directly compete with Shotstack".

That is a source-available license. It is not an open-source license, and the distinction decides things if your own product is a video tool.

Creatomate publishes @creatomate/preview at version 1.6.1, published 3 September 2026, under MIT, with devDependencies only and no runtime dependencies at all.

For a browser bundle that is the lowest dependency surface in this group, and MIT on the client library is worth noting next to a cloud service you pay for by output.

Meishe publishes no React Native package at all, so there is nothing to read for checks 1 to 3.

Its page title reads "Video Editor SDK for React Native & Flutter" and the body states that it "supports React Native, Flutter and other high-quality application development frameworks". No package, no installation page and no sample exists on the site or the docs.

Pricing is not publicly documented, which puts access somewhere between approval-gated and enterprise-only without saying which.

Check 2: Is there a codegen spec, or is it still on the old bridge?

Open the package and search for codegenConfig.

Its presence means the module was built as a turbo-module against the New Architecture. Its absence means an old-architecture native module, and a migration that lands on you.

IMG.LY ships a codegenConfig block with the spec name IMGLYEditorModuleSpec and the Android package ly.img.editor.reactnative.module. react-native-video-trim declares spec VideoTrimSpec with Android package com.videotrim and was scaffolded as a turbo-module. Those are the two New Architecture entries here.

Banuba's package has no codegenConfig. Its peer dependencies accept any React Native version, and its devDependencies pin react-native 0.83.0 with react 19.2.0, which is the newest pair anyone in this group builds against.

That combination is worth sitting with: current on the React Native version, old on the architecture. You get a package built against this autumn's React Native and an interop path you maintain yourself.

react-native-video-processing has no codegenConfig either. Treat it as a legacy bridge module and budget the port before you budget features.

For FFmpegKit, the React Native library provided a JavaScript API with TypeScript definitions, and nothing in the archived repository addresses codegen. Shotstack and Creatomate publish browser JavaScript, so this check does not apply to either, and Meishe publishes nothing to check.

The same pattern shows up on the other side of the cross-platform fence, which I went through in a post on Flutter video editor packages wrapping native engines.

Check 3: When was the React Native package last published, and against which React Native version?

Read the published date, then read the dev dependency pins. The pins tell you which React Native the maintainer last built against, which is a better signal than a README badge.

IMG.LY's package is at version 1.84.0, published 15 October 2026. react-native-video-trim is at 8.2.4, published 5 October 2026, with devDependencies pinning react-native 0.79.2 and react 19.0.0. Both are current enough that your own upgrade cadence sets the pace.

Banuba's package is at 0.55.2, published 9 October 2026. The four releases before it land on 6 October, 12 September, 8 September, and 18 August, which is the most regular cadence of anything in this group.

The version number deserves a glance of its own. A 0.x on a product that has been selling for years usually means the package is much newer than the engine behind it, and that the bridge is where the churn is.

react-native-video-processing is at 1.7.2, published 8 September 2022, pinning react-native ^0.49.5 and react 16.0.0-beta.5. Four years of React Native releases have landed since.

Beyond that package metadata the project publishes very little, so the version gap is most of what there is to read on it, and I would rather say that than score it down quietly.

FFmpegKit's last React Native release in the repository's own version table is 6.0.2, built on FFmpeg 6.0, released 19 September 2023. Shotstack, Creatomate and Meishe publish no React Native package, so there is no date to read for any of the three.

Check 4: Does the editing happen on the device or on someone's server?

This check decides your architecture, your offline behavior and where your users' footage goes. Read whether the project documents on-device processing, a hosted render path, or both.

IMG.LY runs client-side, and IMG.LY also publishes a Node.js package that runs the same engine headlessly on a server for batch rendering. That headless server path is the only documented one of its kind among these eight, which matters when you need the same output from a phone and from a queue.

Banuba runs on device, and its package description states that it works offline. No server render path is published alongside it, so if you later need the same project rendered in a queue, that is a second engine rather than a flag.

Shotstack is the opposite shape. There is no React Native SDK, no Flutter SDK, no Unity SDK, no native iOS or Android SDK and no on-device processing path.

What exists is the Edit API: hosted, JSON in and rendered video out, priced per minute of output, with server-side client libraries for Node.js, Python, PHP and Ruby, plus the browser Studio SDK whose export path uses FFmpeg.

Taking the whole render off the device is the point of it, and the same Edit JSON the browser editor loads is what the Edit API renders. Sign-up is open and the per-minute price is published.

Creatomate splits the same way, and its own Preview SDK installation page is direct about why. The preview "renders video in real time on the user's device, which takes more performance than most phones and tablets have. It therefore runs in desktop browsers only", best on Chrome, Edge and Opera, with Safari and Firefox supported and playback possibly less smooth.

The page tells you to detect the device before loading the SDK and, for phones and tablets, to "show them a video rendered through the API instead of the live preview", at low resolution through a render_scale parameter. On the final file: "Rendering an MP4 in the browser is too unreliable across devices." No React Native path is published.

The strength here is consistency: the same template and the same changes drive both the preview and the server render, so what the user sees is what the API produces. Sign-up is open.

FFmpegKit, react-native-video-trim and react-native-video-processing are all on-device by construction, and all three install from npm with no approval step.

Meishe publishes the widest platform list of the eight: iOS, Android, Web, PC and HarmonyOS Next, with offline SDK operation and a privatized deployment option, plus 8K image processing, HDR export and multi-track editing.

The documented integration path is an Objective-C API and a Java API against a class called NvsStreamingContext, and a web build loaded from a CDN script tag rather than an npm package. The SDK is split into EffectSDK and StreamingSDK.

Check 5: What happens if the package stops being maintained?

FFmpegKit is the worked case, because it already happened.

The arthenica/ffmpeg-kit repository page states: "This repository was archived by the owner on Jul 2, 2026. It is now read-only." The README's "Update (July 2026)" section states that "FFmpegKit has been officially retired" and that development continues as FFmpegKitNext, which "is distributed as source only".

Read what that sentence costs you. Source-only distribution means you build the native binaries for both platforms yourself, in CI, for every FFmpeg configuration flag your feature set needs, and you keep doing it.

The archived README now points readers to community-maintained forks through the package managers, so your other option is trusting a fork whose maintainer you have not met. Both paths start at the successor repository.

Ask the same question of every other option before you commit, because the answer differs by class.

A commercial package with company maintainers, which covers IMG.LY, Banuba and Meishe, puts you in a contract conversation. That is the easiest of these to plan for.

An MIT package with a single maintainer leaves you holding a fork. Survivable while the scope is a trimmer, expensive once the scope is a full editor.

The cloud APIs expose you to an outage you cannot patch, and eventually to migrating your JSON format somewhere else.

With a source-available license your legal reviewer inherits the question of what "directly compete" covers for your product, and that review is worth starting before the integration rather than after it.

The eight side by side

Option	What it is	RN package and license	Codegen	Last RN publish	Where processing runs	Access
IMG.LY CreativeEditor SDK	Vendor SDK with an RN package	@imgly/editor-react-native, "SEE LICENSE IN LICENSE.md" (commercial)	Yes, IMGLYEditorModuleSpec	1.84.0, 15 Oct 2026	On device, plus a headless Node.js server path	Commercial, per target platform, white-labeling and air-gapped option
Banuba Video Editor SDK	Vendor SDK with an RN package	video-editor-react-native, npm field reads MIT, engine is commercial	No	0.55.2, 9 Oct 2026	On device, offline, no server path published	Commercial, token required
Meishe SDK	Vendor SDK, native only	None published	None to read	None	On device, offline operation, privatized deployment	Pricing not publicly documented
FFmpegKit	Community RN module, retired	ffmpeg-kit-react-native, LGPL v3.0, GPL v3.0 with GPL builds	Not addressed	6.0.2, 19 Sep 2023	On device	Open, archived 2 Jul 2026, successor is source only
react-native-video-trim	Community RN module	MIT	Yes, VideoTrimSpec	8.2.4, 5 Oct 2026	On device	Open, npm install
react-native-video-processing	Community RN module	MIT	No	1.7.2, 8 Sep 2022	On device	Open, npm install
Shotstack	Cloud render API plus browser editor	No RN package; @shotstack/shotstack-studio is PolyForm Shield 1.0.0 (source-available)	Not applicable	None	Server, priced per minute of output	Open sign-up, price published
Creatomate	Cloud render API plus browser preview	No RN package; @creatomate/preview (MIT) for desktop browsers	Not applicable	None	Server, preview in desktop browser only	Open sign-up

Every row in that table is stated in the text above, so nothing lives only in the table.

These are the values each project published about itself when I read them. I measured none of them, and the npm command above re-reads four of these columns for you.

Which React Native video editor would I start with?

Feature depth is a separate question from maintenance, and I went through the feature side of these tools in an earlier roundup of mobile video editor SDKs. What follows is the maintenance answer.

A short-form camera app where users trim clips before upload: start with react-native-video-trim. MIT plus a current New Architecture turbo-module plus a scope you can read in one sitting means the fork risk is bounded even with one maintainer.

A multi-track editor inside a consumer app, with a vendor who signs for the bridge: shortlist IMG.LY and Banuba, and let the architecture split them.

IMG.LY declares a codegen spec and publishes a headless Node.js path, so the New Architecture is handled and the same project can render server-side later. Banuba ships more often, builds against a newer React Native, and runs offline, but has no codegen spec and no server render, so you carry the interop path and you keep rendering on the phone.

A template-driven product where users fill in text and media and a finished video comes out: start with Shotstack or Creatomate. The render never touches the phone, both bill against output, and your React Native app only posts JSON and polls for a URL.

A fixed FFmpeg pipeline you already understand, with CI engineers to hand: start from the FFmpegKitNext source. You accept a build burden in exchange for format coverage and no license fee, having read the patents note first.

HarmonyOS Next or desktop alongside iOS and Android: start a conversation with Meishe, and go in expecting to write the React Native bridge yourself against NvsStreamingContext.

Two packages pass all five checks, and both shipped in October

The screen sorts these options by what each project publishes about its React Native layer.

IMG.LY and react-native-video-trim give you a current turbo-module to read. Banuba gives you the most frequent releases and the newest React Native pin, with no codegen spec behind them. react-native-video-processing gives you MIT source and a four-year-old bridge.

FFmpegKit gives you an archive notice and a source-only successor. Meishe names React Native in its page title and publishes nothing for it. Shotstack and Creatomate move the work to a server, which changes your architecture more than your feature list.

Before the device post, the next thing I open is node_modules for the two packages that declare a codegen spec.

Questions I get asked about this

Does a missing codegenConfig mean the package will not work on the New Architecture?

It can still work through the interop layer, but you are relying on a compatibility path rather than a generated spec, and nobody upstream is testing your case.

For react-native-video-processing, with react-native pinned at ^0.49.5, assume you are the one maintaining that path. For Banuba, pinned at 0.83.0, the package is current enough that the interop path is at least being exercised against a recent React Native.

Can I use FFmpegKit's last release and deal with it later?

You can install 6.0.2 from September 2023 today, and it will keep building until something in your toolchain moves.

The cost arrives on the next iOS or Android SDK bump, when no upstream release exists and you are either patching the archive yourself or moving to FFmpegKitNext and its source-only builds.

Is PolyForm Shield 1.0.0 open source?

No, it is source-available. You can read and use the code, including commercially, under Shotstack's stated condition that your application does not directly compete with Shotstack.

That condition is the part to send to your legal reviewer before you build on it.

Why does an npm package say MIT when the SDK costs money?

Because the field describes the package, not the engine it loads. A vendor bridge can be MIT while the native binaries behind it need a commercial token, and the npm field has no way to say so.

IMG.LY handles this by putting "SEE LICENSE IN LICENSE.md" in the field. When a vendor package shows a bare MIT, check whether the thing you are licensing is the wrapper or the product.

Why not just use a cloud API and skip native code entirely?

That is a real option if your editing is template-driven and your users tolerate a round trip, which is how Shotstack's Edit API and Creatomate's REST API are shaped.

It stops being an option when you need frame-accurate scrubbing with no network, since Creatomate's installation page puts the Preview SDK in desktop browsers only and Shotstack documents no on-device path.