FFmpegKit Is Gone: The Complete 2026 Migration Guide (React Native, Flutter, Kotlin & Web)

If you’re reading this because a build just failed, a video feature went dark, or a dependency audit flagged ffmpegkit in a codebase you didn’t write yourself, this guide is for you.

As of April 1, 2025, FFmpegKit’s native binaries were removed from Maven Central, CocoaPods, and npm. That’s over a year ago now, and yet developers are still running into this problem daily, often inside AI-generated codebases where the dependency was scaffolded in automatically, without anyone thinking twice about its retirement status.

This is not a quick “swap the library” situation. Picking the right FFmpegKit replacement depends on your platform, your codec requirements, your licensing exposure, and whether your app runs natively or in a browser. We’ve seen teams get this wrong in both directions: choosing something too heavy for their use case, or choosing something too lightweight and finding out it doesn’t support the filter chain they actually need.

This guide covers every major platform: React Native, Flutter, Android with Kotlin Multiplatform, iOS, Web with ffmpeg.wasm, and .NET/Unity. We also cover cloud transcoders and where AI-native development workflows fit into all of this. Mobile video processing alone is part of a rapidly growing market. The broader video processing solutions space is already valued at over $20 billion in 2025, and the tooling around it is changing fast.

If you’re building with Lovable, Bolt.new, Cursor, or Claude Code, there’s a specific section below for you.

What Happened to FFmpegKit?

FFmpegKit was the standard wrapper for FFmpeg across Android, iOS, macOS, tvOS, Flutter, and React Native. Arthenica Ltd. maintained it for years and it worked well. Then, on January 6, 2025, the maintainers announced retirement, citing two main factors: the ongoing effort of keeping pace with upstream FFmpeg changes, and growing legal uncertainty following MPEG LA’s acquisition by Via-L, which raised questions about codec patent exposure for distributed apps.

The timeline went like this:

The source code remains on GitHub. But active maintenance stopped, and the binaries are gone. Any build that tries to pull them will fail with a 404.

How This Affected Your App

1. CI/CD Pipeline Breakage

This is usually where developers first hit the wall. Prebuilt binaries go offline, and builds that worked for months start failing with dependency resolution errors.

If you saw something like Could not resolve com.arthenica:ffmpeg-kit-full in Gradle, or ERROR: Could not find pod 'ffmpegkit' in Xcode, this is why. The same applies to React Native projects pulling ffmpeg-kit-react-native from npm, which now installs but links to nothing at runtime.

Quick check: run a search for ffmpegkit, ffmpeg-kit, or ffmpeg_kit in your package.json, pubspec.yaml, or build.gradle. If it’s there and you’re still pulling from the original source, your build is living on borrowed time.

2. App Feature Breakage

The CI failure is the obvious symptom. The deeper issue is what stops working at runtime when developers do get past the build step by pinning an old cached version: video trimming, transcoding, compression, audio/video muxing and demuxing, live streaming, and custom filter chains all break. These aren’t edge features in most media apps. They’re the core product.

3. Legal and Licensing Risk

This one gets overlooked. FFmpegKit bundled codecs covered by MPEG LA patents. If you’re distributing an app that was using FFmpegKit, and you haven’t reviewed your licensing position since the Via-L acquisition, it’s worth a conversation with legal counsel, especially for apps distributed at scale in the US or EU.

Criteria for Choosing a 2026 Alternative

The current blog’s four-point framework is still solid. We’ve added a fifth criterion that matters specifically for teams building on AI-generated codebases.

1. Platform Support

Which targets do you actually need? Android only, iOS only, both, web, desktop, or server-side? Not every library covers all of these, and the best option for a pure React Native app is often wrong for a Flutter app or a web app.

2. Capabilities

There’s a big gap between “play a video” and “apply a custom filter chain to a live stream.” Know your actual requirements before picking. Libraries like Ijkplayer are excellent for playback but useless for encoding. Libraries like GStreamer can do almost anything but require real effort to ship on mobile.

3. Licensing and Patents

LGPL gives you more flexibility than GPL for commercial apps. Some FFmpeg builds include GPL components that restrict distribution. Some cloud options sidestep this entirely by processing server-side. Know what you’re distributing.

4. Maintenance and Community

Check when the last commit was. Check whether issues get responses. A library that was active in 2023 but hasn’t been touched since is a risk. For mission-critical video pipelines, this is not negotiable.

5. AI Toolchain Compatibility (2026 Addition)

If your codebase was generated or scaffolded by Cursor, Lovable, Claude Code, or a similar tool, check whether the replacement integrates cleanly with that toolchain. Some libraries require complex native build steps that AI-generated scaffolding handles poorly. Libraries with clean package manager support (npm, pub.dev, NuGet, SPM) cause fewer problems in vibe-coded apps.

For a broader comparison of best FFmpeg alternatives in 2026, we’ve covered the full landscape separately.

Platform-by-Platform Migration Guide 2026

1. React Native and Expo

Both react-native-ffmpeg and ffmpeg-kit-react-native are gone. For basic editing, react-native-video-processing handles trimming via native APIs (no FFmpeg binary needed). For Expo managed workflows specifically, the cleanest approach is to offload video processing to a cloud API and bundling FFmpeg in a managed Expo app adds too much complexity.

For help architecting a React Native video pipeline as part of a hybrid mobile app development project, our team works through these decisions regularly.

2. Flutter

ffmpeg_kit_flutter is marked unmaintained on pub.dev. For basic editing, tapioca uses native iOS/Android APIs for filters and overlays. For full FFmpeg access, you’ll bundle FFmpeg directly via Swift Package Manager on iOS and Gradle on Android.

3. Android (Native and Kotlin Multiplatform)

• Native Android:

VideoKit-FFmpeg-Android is the cleanest direct replacement for FFmpegKit on Android. It adds FFmpeg as a Gradle dependency with a built-in JNI layer, so you skip most of the NDK setup.

4. iOS and macOS (Swift)

FFmpeg-iOS builds FFmpeg into your project via Swift Package Manager. But here’s the shortcut: AVFoundation (built into iOS/macOS) already handles trimming, format conversion, and basic export natively. If that’s all your app needs, you can drop FFmpegKit entirely and use AVFoundation directly, which means, no migration needed.

5. Web and WASM (@ffmpeg/ffmpeg)

ffmpeg.wasm runs FFmpeg entirely in the browser via WebAssembly, no server required. The v0.12 release changed the API significantly, so if you’re upgrading from older versions, you’ll need to update your code. Performance is the real constraint: ffmpeg.wasm is significantly slower than native FFmpeg. For clips under 2 minutes, it’s workable. For longer clips or batch processing, use a server instead.

6. .NET, Unity, and C

If you were using FFmpegKit in a Unity game or .NET desktop application, there are two paths forward:

• FFmpeg.AutoGen: Provides .NET bindings to FFmpeg’s C API (the underlying technology FFmpegKit used)
• ffmpeg-unity: A community-maintained package that makes FFmpeg easier to use specifically in Unity projects

Note: These require more technical setup than FFmpegKit did, as the C API is more complex than what FFmpegKit simplified for you.

7. Cloud Transcoders (Server-Side Processing)

Not every app needs to process videos on the user’s device. If your app can send videos to a server for processing, cloud-based solutions might be better:

Popular cloud options in 2026:

• AWS Elemental MediaConvert: Enterprise-grade, pay per minute of video processed
• HandBrake (CLI): Free, open-source, works on build servers
• Bento4: For adding DRM protection to streaming videos
• Av1an: Best for high-quality video compression (AV1/VP9/HEVC)

When to choose cloud: If your app doesn’t need real-time processing, if you’re processing long videos (over 2 minutes), or if you’re doing batch processing of many videos at once.

The AI-Native Approach to Mobile Video in 2026

Here’s something we see regularly: a developer uses Cursor, Lovable, or Claude Code to scaffold a React Native app. The AI generates a working video feature, pulls in ffmpeg-kit-react-native as the dependency, and the developer ships it. Everything looks fine in development because they’re on a cached environment. Then it hits production CI, or a teammate clones the repo fresh, and the build fails with a 404.

This isn’t a criticism of vibe-coded apps. The dependency existed, the AI’s training data referenced it, and the AI did what it was trained to do. The problem is that replacing it is not just a package swap. The right replacement depends on the platform target, the specific video operations in use, the codec requirements, and whether the app can offload processing to a server or needs on-device capability.

We’ve found that vibe-coded apps with broken video pipelines need two things: a correct dependency replacement and, in many cases, a rethink of the media architecture. Apps built with AI tools often take a pattern that worked in a demo and apply it to a feature that has different performance or licensing requirements. Video processing is one of the areas where this gap shows up most clearly.

The teams that fix this fastest are the ones that treat it as an architecture decision, not a find-and-replace. Should processing happen on-device or server-side? Does the app actually need raw FFmpeg access, or would a lighter native API cover it? Is there codec patent exposure in the current implementation?

Our AI development services team works through exactly this kind of audit for apps built with AI coding tools. We assess the existing media stack, identify what actually needs FFmpeg versus what can use a lighter alternative, and implement a production-ready fix.

Community Forks and What Is Being Maintained

FFmpegKit’s source code is still on GitHub and the community has not left it entirely alone. Several forks have appeared since the April 2025 retirement, though none has emerged as a clear successor.

The Flutter community has been most active. GitHub discussions around ffmpeg_kit_flutter alternatives have driven interest toward tapioca, video_manipulation, and direct platform-channel implementations. The React Native community has mostly converged on react-native-video-processing for lighter use cases and direct FFmpeg builds for heavier ones.

The Kotlin Multiplatform ecosystem is developing its own path with ffmpeg-kt, which is seeing active commits as of early 2026. This is probably the most interesting fork space to watch if you’re building cross-platform Kotlin applications.

What has not happened is a single drop-in replacement that covers Android, iOS, Flutter, and React Native the way FFmpegKit did. The community is solving this platform by platform, which is why this guide is structured the way it is.

Got a Vibe-Coded App With Broken Video? We’ll Fix It.

If you built your app on Lovable, Cursor, or Claude Code and your video pipeline broke when FFmpegKit went offline, we can help.

We have seen this pattern enough times now to move through it quickly. The typical engagement starts with a media stack audit: what’s in the dependency tree, what’s actually being used, what’s broken, and what needs to change. From there, we implement the right replacement for your specific platform and use case, wire it into your CI/CD, and deliver a production-ready fix.

We also handle the situations where the issue goes deeper than a library swap. Some AI-generated video pipelines are architecturally mismatched for what the app actually needs to do. We can rebuild that foundation while preserving the application logic that works.

Our vibe coding support service is specifically designed for teams who built fast with AI tools and now need real engineering to get to production. We embed into your codebase, work with your existing stack, and don’t require a full rewrite.

Conclusion

FFmpegKit is gone and that’s been true for over a year. The 2026 reality is that developers are encountering this not because they made a bad choice in 2024, but because the ecosystem kept moving while one widely-used dependency did not.

The good news is that the replacement landscape has matured. React Native, Flutter, Kotlin Multiplatform, iOS, and web each have credible options. Cloud transcoders have gotten better and cheaper. And for apps built with AI coding tools, the migration path is well-worn enough that experienced teams can move through it without a complete rebuild.

The choice you make here will carry your media pipeline for the next few years, so it’s worth making it deliberately rather than defaulting to whatever looks most like FFmpegKit. Use the criteria in this guide, match your platform to the right section, and if the decision feels complex, that’s because it sometimes is.

We’re here if you need someone to work through it with you.

Frequently Asked Questions

1. Is FFmpegKit completely dead, or can I still use it?

FFmpegKit is retired and its native binaries were removed from Maven Central, CocoaPods, and npm on April 1, 2025. The source code remains on GitHub, but there are no official releases, no security patches, and no maintainer actively triaging issues. You can technically fork and build it yourself, but any production app still depending on the original package distribution is pulling from a dead source.

2. What is the best FFmpegKit alternative for React Native in 2026?

For most React Native apps, react-native-video-processing covers trimming, compression, and watermarking without needing a full FFmpeg binary, and it works with Expo. If you need raw codec access or custom filter chains, the recommended path is to bundle FFmpeg directly via Gradle/NDK on Android and via Swift Package Manager (FFmpeg-iOS by kewlbear) on iOS.

3. What replaces ffmpeg_kit_flutter on pub.dev?

ffmpeg_kit_flutter is marked discontinued on pub.dev. The current replacements are tapioca and video_manipulation for most editing needs (trim, compress, watermark). For full FFmpeg access, the approach is to use platform channels with FFmpeg-iOS on the iOS side and VideoKit-FFmpeg-Android on the Android side.

4. Does ffmpeg.wasm work as a replacement for browser-based apps?

Yes. @ffmpeg/ffmpeg (ffmpeg.wasm) runs FFmpeg in the browser via WebAssembly with no server required. Note that the API changed in v0.12: createFFmpeg and fetchFile are deprecated, and readFile now returns a Uint8Array instead of a Buffer. For short clips it works well. For longer or batch processing, a server-side cloud transcoder is usually faster.

5. Is there a Kotlin Multiplatform alternative to FFmpegKit?

Yes. ffmpeg-kt is the current KMM-compatible wrapper for FFmpeg. It lets you write shared media processing logic in Kotlin that runs on both Android and iOS, which is the most common ask from teams using Kotlin Multiplatform for cross-platform mobile development.

6. My CI/CD pipeline broke with a 404 error on an FFmpegKit dependency. How do I fix it?

The 404 means the build is trying to resolve a package that no longer exists at its original distribution URL. The fix is to replace the dependency entirely, not pin an old version or mirror the artifact. Identify exactly which FFmpegKit package is referenced (Android, iOS, React Native, or Flutter), then follow the platform-specific replacement in the migration guide above. If the dependency is buried in a transitive dependency from another library, you may need to find which library pulled it in and update that library first.

7. Do I need a license to use FFmpeg alternatives?

It depends on the library. Most FFmpeg builds are LGPL by default, which allows use in commercial apps with some conditions. Some builds include GPL components, which are more restrictive for distribution. Cloud transcoders like AWS Elemental MediaConvert sidestep this entirely since you’re calling an API rather than distributing binaries. Always check the license of the specific build or wrapper you’re using, especially if you distribute in large markets.

8. Can AI coding tools like Cursor or Claude Code generate correct FFmpegKit migration code?

They can generate a starting point, but you need to verify it against the current API. AI tools trained before mid-2025 may suggest the old ffmpeg.wasm pattern (createFFmpeg, fetchFile) or reference ffmpeg-kit-react-native as if it’s still active. The v0.12 ffmpeg.wasm API changes and the platform-specific replacement libraries are recent enough that AI-generated code often needs manual correction. Treat the output as a draft, not a final implementation.

9. What happened to ffmpeg-kit-react-native on npm?

The package still exists on npm but the native binaries it links to at runtime were removed when FFmpegKit retired on April 1, 2025. Installing it no longer gives you a working implementation. The package entry itself may still install without errors, which makes this particularly confusing. Runtime failures, not install-time errors, are often the first sign.

10. We built our app using an AI coding tool and the video features are broken. Where do we start?

Start with a dependency audit: search your package.json, pubspec.yaml, and build.gradle for any reference to ffmpegkit, ffmpeg-kit, or ffmpeg_kit. Map what each reference is actually doing in the app (playback, trimming, encoding, streaming). Then match each use case to the appropriate replacement from the platform guide above. If the video architecture is more complex or the AI-generated code mixed several responsibilities into one FFmpegKit call, it may be worth a proper media stack review before picking a replacement.