Every platform FFmpegKit supported, React Native, Flutter, Android, iOS, macOS, and the web, has a working replacement in 2026. On mobile, the choice comes down to whether you need raw codec access or just standard editing operations; the former means bundling FFmpeg directly via Gradle/SPM, the latter means lighter native-API wrappers. On the web, ffmpeg.wasm runs entirely in the browser but comes with a real performance ceiling. Across all platforms, the path forward is clear, it’s just not the same path for everyone.

FFmpegKit didn’t just power one app. It was the de facto solution for cross-platform video processing in mobile development for years, a single, well-documented library that abstracted FFmpeg across React Native, Flutter, Android, iOS, and macOS. When it went unmaintained, it didn’t just leave a gap in package.json files. It left teams mid-project with no obvious landing spot.

The added wrinkle is that the deprecation didn’t happen all at once. react-native-ffmpeg was discontinued first, then ffmpeg-kit-react-native followed. ffmpeg_kit_flutter lingered longer before pub.dev started showing the unmaintained flag. Teams that stayed on older versions kept shipping, until build pipelines broke, Xcode updated, or Gradle changed something. That’s the wall most people hit.

The replacements exist. But they’re fragmented by platform, and the right answer for a Flutter team looks different from the right answer for someone building a React Native app in an Expo managed workflow. Here’s the full breakdown.

React Native and Expo

Both react-native-ffmpeg and ffmpeg-kit-react-native are gone. If either is still in your package.json, here’s what replaces them.

Standard editing (trim, compress, watermark): react-native-video-processing handles trimming and basic editing by calling native platform APIs directly, with no full FFmpeg binary bundled and smaller footprint.

However, note that this package is inactive (last update 2016) and NOT Expo-compatible out of the box.

For Expo managed workflows, the practical recommendation is to offload video processing to a cloud API and return the processed file to the client, as bundling FFmpeg in a managed Expo app introduces native module ejection, build config changes, and binary size issues.

`// Before import { RNFFmpeg } from ‘ffmpeg-kit-react-native’;

// After import { VideoPlayer, Trimmer } from ‘react-native-video-processing’;`

Raw codec access or custom filter chains: You’re bundling FFmpeg directly. On Android that means Gradle and NDK; on iOS that means SPM or a manual XCFramework. FFmpeg-iOS by kewlbear handles the iOS side, VideoKit-FFmpeg-Android handles Android. It’s heavier and takes longer to set up, but it gives you the same level of control you had with FFmpegKit.

Expo managed workflow specifically: expo-video covers playback. For processing, the practical recommendation is to offload to a cloud API and return the processed file to the client. Bundling FFmpeg in a managed Expo app introduces enough complexity, native module ejection, build config changes, binary size, that a server-side approach is almost always cleaner.

Flutter

ffmpeg_kit_flutter carries the unmaintained flag on pub.dev. The two main replacements depend on how much FFmpeg access you actually need.

Basic editing: tapioca uses AVFoundation on iOS and Mp4Composer on Android. It covers filters, text overlay, and image overlay (note: trimming and compression support is limited/unconfirmed), has a low binary size impact, but is NOT actively maintained, last published version 1.0.6+1 from September 2022. video_manipulation covers similar ground but is iOS-only with no Android implementation, so compare carefully before you commit.

`# pubspec.yaml dependencies: tapioca: ^0.2.0

or video_manipulation: ^1.0.0`

Full FFmpeg access: The architecture mirrors React Native, FFmpeg-iOS (kewlbear) via SPM on iOS, VideoKit-FFmpeg-Android via Gradle on Android, connected through Flutter’s platform channel. It takes setup work, but it’s a stable pattern.

Playback only: Flutter’s official video_player package and better_player both handle playback without any FFmpeg dependency. If video playback is your only requirement, you don’t need FFmpeg at all.

Android — Native and Kotlin Multiplatform

Native Android: VideoKit-FFmpeg-Android is the closest direct replacement. It adds FFmpeg as a Gradle dependency with a built-in JNI layer, so you skip most of the NDK configuration work that a fully manual integration would require.

// build.gradle.kts dependencies { implementation("com.videokit:ffmpeg-android:6.0.1") }

Note: Verify the exact Maven coordinate from the package’s latest documentation before use

Kotlin Multiplatform (KMM): ffmpeg-kt provides a KMM-compatible FFmpeg interface for shared media processing logic on Android, macOS, Linux, Windows, and JVM—but NOT iOS. For iOS support, you’ll need separate native FFmpeg integration via FFmpeg-iOS (kewlbear) on the iOS side.

iOS and macOS (Swift)

FFmpeg-iOS by kewlbear builds FFmpeg and associated libraries into .xcframeworks via Swift Package Manager. Adding it to an Xcode project is straightforward, add the SPM dependency, and you get --enable-audiotoolbox support included, which means Apple hardware codec acceleration works the same way it did with FFmpegKit’s iOS binaries.

// Add via Swift Package Manager in Xcode // <https://github.com/kewlbear/FFmpeg-iOS>

One thing worth checking before you add any third-party dependency: AVFoundation covers trimming, format conversion between common formats, and basic export natively on both iOS and macOS. If that’s all your app needs, there’s no migration needed at all, you can drop FFmpegKit and call AVFoundation directly.

Web and WASM

This platform was missing from most of the early FFmpegKit replacement coverage, which is part of why @ffmpeg/ffmpeg queries show high impressions and low clicks because people are searching, not finding clear answers.

@ffmpeg/ffmpeg (ffmpeg.wasm) runs FFmpeg in the browser via WebAssembly. No server required, no binary shipped to users, everything happens client-side. The v0.12 release changed the API significantly, the old createFFmpeg / fetchFile pattern is deprecated:

`// Old pattern (v0.11 and below) — deprecated import { createFFmpeg, fetchFile } from ‘@ffmpeg/ffmpeg’; const ffmpeg = createFFmpeg({ log: true }); await ffmpeg.load(); ffmpeg.FS(‘writeFile’, ‘input.mp4’, await fetchFile(file)); await ffmpeg.run(‘-i’, ‘input.mp4’, ‘output.mp4’);

// New pattern (v0.12+) import { FFmpeg } from ‘@ffmpeg/ffmpeg’; import { fetchFile, toBlobURL } from ‘@ffmpeg/util’;

const ffmpeg = new FFmpeg(); await ffmpeg.load(); await ffmpeg.writeFile(‘input.mp4’, await fetchFile(file)); await ffmpeg.exec([‘-i’, ‘input.mp4’, ‘output.mp4’]); const data = await ffmpeg.readFile(‘output.mp4’); // returns Uint8Array`

readFile now returns a Uint8Array instead of a Buffer. If you’re seeing type errors in existing ffmpeg.wasm code after upgrading, that’s where to look first.

Performance is the real constraint here. ffmpeg.wasm is slower than native FFmpeg which is significantly slower for complex operations. For clips under two minutes, it’s workable for most use cases. Anything longer, or any batch processing scenario, should go server-side.

.NET, Unity, and C

FFmpeg.AutoGen provides auto-generated unsafe bindings to FFmpeg’s C API for .NET. If you were using FFmpegKit in a Unity project or a .NET desktop application, this is the current path.

// FFmpeg.AutoGen - example of opening a format context
AVFormatContext* pFormatContext = ffmpeg.avformat_alloc_context();
int result = ffmpeg.avformat_open_input(&pFormatContext, url, null, null);
// avformat_open_input signature: (AVFormatContext**, string, AVInputFormat*, AVDictionary**)

The avformat_open_input function signature trips up developers coming from FFmpegKit because the parameter order and pointer handling are different from what the Kit abstracted away. The pattern above is the current signature as of FFmpeg 7.x.

For Unity specifically, the community-maintained ffmpeg-unity package wraps FFmpeg.AutoGen with Unity-friendly APIs.

Cloud Transcoders (Server-Side Processing)

Cloud transcoders are worth serious consideration in 2026, especially for apps that don’t need on-device processing. No binaries to ship, no licensing complexity for distributed codecs, and processing scales with your workload rather than device capability.

• AWS Elemental MediaConvert handles server-side transcoding with enterprise SLAs and integrates cleanly with modern CI/CD. Pricing is per-minute-of-output, which scales reasonably for most app workloads.
• HandBrake remains a solid open-source option for desktop or build-server transcoding via CLI. Not a library, but scriptable and reliable.
• Bento4 covers MP4 and DASH packaging with DRM support, useful for streaming pipelines that need segment packaging rather than full transcoding.
• Av1an is the current recommendation for batch AV1/VP9/HEVC encoding where quality-per-bit matters. Actively maintained on GitHub.

For the full context on why FFmpegKit was deprecated and how to decide between migration paths, see: No More FFmpegKit? Don’t Panic—Here’s What’s Next

If You’re Also Reconsidering Your Media SDK Stack

Some teams use a migration like this as a moment to look at whether they want to keep building around FFmpeg directly, or move to a higher-level SDK. Three options that come up regularly are BytePlus Effects, Banuba SDK, and IMG.LY.

BytePlus Effects vs. Banuba vs. IMG.LY – Full Comparison

• The practical differences as Banuba has direct FFmpeg integration (v5.1.3 inside), which makes it the most direct transition for teams coming off FFmpegKit but the mental model is similar. Whereas, BytePlus and IMG.LY use proprietary or indirect FFmpeg internals, which trades low-level flexibility for a more managed API.
• Platform coverage is also a real factor, Banuba is iOS and Android only, while BytePlus and IMG.LY both support web as well.
• Pricing structures differ too: Banuba is startup-friendly with tiered pricing, BytePlus runs MAU-based enterprise pricing, and IMG.LY charges per SDK which can add up if you’re combining multiple products.

Every Platform Has a Path — Pick the One That Fits Your Stack

FFmpegKit’s deprecation spread across platforms over time, which made it easy to keep pushing the migration forward. But in 2026, all the packages are effectively unmaintained, and the alternatives are stable enough that there’s no reason to wait.

The decision isn’t complicated: if you need basic editing, use the native-API wrappers which are react-native-video-processing, tapioca as they’re lighter and don’t require FFmpeg at all, but note both packages are inactive/outdated and may require maintenance work for modern SDK versions.

The migration itself is straightforward once you know which path applies to you. The harder part was figuring out which packages were actually maintained and which ones just hadn’t been formally archived yet. That part’s done now.

Ready to Migrate? Let’s Talk.

We’re available 24/7 to guide your transition from FFmpeg.

No headaches. No guesswork. Just smooth, supported migration.

Contact us now to start your migration journey