FFShare: an Android app that compresses media with ffmpeg before sharing

The whole product is a compression step before the share sheet

FFShare is described in one line: an Android app to compress image, video and audio files through ffmpeg before sharing them. There is no cloud service, no account, and no library of editing tools. The scope is a single point in a workflow that already exists on a phone.

The path through the app is therefore short. You pick a file, you pick a compression setting, the app runs ffmpeg on it, and then the compressed result goes out through the normal Android share mechanism so it lands in a messaging app, a mail client or a drive. The repository carries four phone screenshots under fastlane/metadata/android/en-US/images/phoneScreenshots/, which is where the store listing images come from, so the intended flow is visible there even before installing anything.

The primary language is Kotlin, and the app is a normal Gradle Android project: the top level holds build.gradle, settings.gradle, gradle.properties, the gradlew wrapper, an app/ module, and separate directories for fastlane, f-droid and google_play. Nothing about the layout suggests a service or a backend.

What makes this app different from a generic image compressor is the codec layer. The compression is done by ffmpeg, which means the format and encoder choices available in the app are the ones ffmpeg supports.

The ffmpeg-kit dependency and the build step that has no fallback

The used-libraries list is short: FFmpegKitNext and Timber. The first is the maintained fork of the ffmpeg-kit packaging project, which is what turns ffmpeg into something an Android app can call. The second is Jake Wharton's logging library.

The build section is where the friction sits, and it is a single instruction:

./build_ffmpegkit.sh

The description says to create ffmpeg-kit binaries by running that script, which means the native side of the dependency is not shipped in the repository and has to be produced before the app will link against it. This is a normal arrangement for ffmpeg-kit based projects, because the native binaries are large, multi-ABI, and normally published as separate artefacts rather than committed.

What the repository does not do is document a path for someone who cannot run the script, or describe which ABIs the resulting binaries cover. The two directories named google_play/ and f-droid/ hold the per-store build configuration, which is a hint that the ABI set differs between distribution channels, but the detail is not spelled out in the README. If you are evaluating this app for a build you have to reproduce, that script and its output are the first thing to read.

The presence of generate_test_files.sh and github_build_release.sh at the root shows the release is assembled by script rather than by hand, which is reassuring for repeatability.

Three distribution channels and what each one implies

FFShare is available through more than one route, and the badges in the README make that explicit. It is listed on F-Droid under the identifier com.caydey.ffshare, it is offered through Obtainium, which points at the GitHub release, and it is published on Google Play through the google_play/ directory in the repository.

This matters for a user choosing an install source, because the three paths are not equivalent. The F-Droid listing is the version built by the F-Droid build server from the tagged source, using the f-droid/ metadata in the repository. The Obtainium link points at a GitHub release and carries a long configuration block that sets version detection and release filtering, which tells you the app is delivered as a prebuilt APK from the release pipeline rather than compiled on the device. The Google Play route is the usual one for people who want automatic updates from the store.

The package name com.caydey.ffshare is the stable identifier across all of them, and the F-Droid and Obtainium entries both point at that same id, so a user moving between sources is moving between builds of the same app rather than between forks.

The README also links to a privacy document in the repository, and a PRIVACY.md file sits at the top level next to the licence.

Version numbering, release cadence, and the 2.0.0 gap

The release history has an odd shape that is worth understanding before you pick a version. There is a tag named u2.0.0, titled FFShare 2.0.0, dated 2026-08-14. Before that come v1.3.3 from 2024-12-07 and v1.3.2 from 2024-07-13.

Two things stand out. The 2.0.0 tag carries a u prefix rather than a v prefix, so a script that filters on v-prefixed tags will not pick it up, which matters for anyone automating an Obtainium or F-Droid style build. And the gap between v1.3.3 in December 2024 and the 2.0.0 release in August 2026 is about twenty months, so the 1.3.x line was the long-lived one and 2.0.0 is a recent jump to a new major version.

The repository is not archived, and the last push was on 2026-08-14, the same date as the 2.0.0 release. The project is therefore current, but the history shows long gaps between releases rather than a steady stream, so there is no assumption to make about when the next version will arrive.

Nothing in the README describes what changed in 2.0.0. There is no changelog, no migration note, and no upgrade section, so anyone moving up from 1.3.x has to read the diff or the source to find out.

What the GPL-3.0 licence means for an Android app

FFShare is released under GPL-3.0, and that is a meaningful constraint for anyone thinking about modifying it or shipping a derivative. This is not legal advice, and the details depend on how you distribute, but the practical shape is well known: a derivative distributed to users must be offered under the same licence, and the corresponding source must be made available to those users.

For a personal install from F-Droid, Obtainium or Google Play, the licence places no obligation on the user. For a fork shipped as an APK, or for an app built from this source and published commercially, the copyleft obligation applies to the distributed binary.

The licence also sits on a stack that carries its own terms. FFmpeg itself is licensed under LGPL or GPL depending on the build, and the ffmpeg-kit wrapper packages those binaries. Shipping a build of FFShare means shipping ffmpeg binaries, so anyone doing commercial distribution needs to look at both the app licence and the licences of the native libraries that the build script pulls in. The repository does not enumerate the codecs enabled in the ffmpeg-kit build, which is exactly the detail a compliance review would want.

The ARTWORK directory and fastlane metadata indicate a proper release pipeline with artwork and store copy, so the project is maintained with distribution in mind rather than as a research artefact.

Where FFShare is the wrong choice

Several boundaries are visible in the repository rather than hidden. It is an Android app, so it is not an option for iOS, desktop or a browser workflow, and there is no cross-platform library in the project. The described function is also narrower than a general media tool: it compresses and then shares, and the repository does not present a batch, scheduling, or automation layer.

The dependency on ffmpeg-kit is the other real constraint. FFmpegKitNext, the ffmpeg-kit fork named in the used-libraries list, is what supplies the encoders, and the app cannot be built without the native binaries that build_ffmpegkit.sh produces. For a user installing from a store this is invisible. For a developer who wants to contribute a patch or self-host a build, it means reproducing a native toolchain step, and the README gives one line of instruction for it without elaborating on platforms or failure modes.

A third consideration is the ffmpeg-kit situation in general. The ffmpeg-kit lineage is a third consideration: the encoders come from a fork, and a project built on such a dependency inherits the fork's maintenance horizon rather than a first-party commitment. The repository does not discuss what happens if that fork stops, so a long-lived plan should not assume the native layer stays where it is today.

If you need an editor, a converter that targets specific output formats, or batch processing, this app is the wrong shape. If you want one more tap before sharing a large photo, it is exactly the right size.

Editorial conclusion

FFShare fits an Android user who regularly sends oversized photos, clips and recordings and wants one share-sheet flow that compresses on the device first, and the GPL-3.0 licence suits anyone willing to keep the derivative source available; it is the wrong tool for a cross-platform workflow or for a commercial app that cannot carry copyleft obligations, and before you build or install it you should check whether ./build_ffmpegkit.sh can produce ffmpeg-kit binaries for your target ABI, because the app depends on that step and the repository does not document a prebuilt fallback.

Frequently asked questions

Official sources

1. caydey/ffshare on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases