F-Droid 2.0 arrives as a Kotlin and Jetpack Compose rewrite, just as Google tightens sideloading

F-Droid has shipped version 2.0 of its Android client, and according to a dev.to write-up it is a ground-up rewrite rather than an incremental refresh. Dated September 24, 2026, the release caps more than a year of development, fourteen public test releases and an independent security audit, and moves the codebase onto Kotlin and Jetpack Compose. The timing matters: Google's Android developer verification requirements start applying in Brazil, Indonesia, Singapore and Thailand on September 30, 2026, and the article frames the collision as an existential test for how F-Droid distributes software.

What the rewrite changes

According to the dev.to post, the move to Kotlin and Jetpack Compose is a deliberate bet on long-term maintainability and on lowering the barrier for contributors, who are now more likely to know declarative UI toolkits than the client's older stack. The user-visible changes include:

• A simplified three-tab layout — Discover, Search and My Apps — replacing the clutter of earlier versions.
• Background updates on by default, ending the reliance on manual pull-to-refresh.
• A broader category taxonomy, with 17 sub-genres for games and dedicated groupings for security tools such as VPNs, firewalls and password managers.
• A higher platform floor: the minimum SDK is now Android 7, letting the client use modern system APIs without heavy backward-compatibility shims.

Audit, funding and paused features

Before release, the client went through a security review run by the Open Technology Fund's Security Lab in collaboration with Convocation, with funding support that the write-up credits to the Calyx Institute and NLnet. Two features were paused to make the rewrite possible: the panic trigger and the F-Droid Privileged Extension. Core browsing and installation, the article says, came out of the process more robust than before.

The verification rules arriving alongside it

Google's stated goal, per the dev.to article, is to curb malware in the sideloaded ecosystem: any app running on a Google-certified device must be associated with a registered, verified developer, regardless of how it was distributed. The policy effectively creates three tiers:

• Full distribution, requiring formal identity verification and package-name registration, with the APK signed by the developer's own private key.
• Limited distribution, a simplified path for individuals and students that skips government ID checks but caps distribution at 20 devices.
• Sideloading through an "advanced flow", a deliberately restrictive mechanism intended to add friction and slow social-engineering attacks.

The article notes that ADB workflows are unaffected, so developers pushing debug builds to their own hardware over USB will see no change.

The signing mismatch at the center

The crux for F-Droid is architectural. The project frequently builds apps from source and signs them with its own keys rather than the original developers' keys, and roughly 85% of the catalog relies on this infrastructure-based signing, the write-up reports. Those apps do not map to a single developer identity in the way Google's framework expects. In an open letter signed by the Electronic Frontier Foundation and the Free Software Foundation Europe, the project warns that without a mechanism to coordinate key registration between thousands of contributors and the F-Droid build pipeline, a large portion of the catalog could face restricted access on certified devices — and that an overly friction-heavy "advanced flow" threatens to make open-source delivery unusable for mainstream users.

Testing a repository against the new client

For maintainers of custom repositories, the article walks through the standard tooling: fdroid init generates keys and directories, APKs go into the repo/ subdirectory, and fdroid update writes the index files the client parses. Serving the directory locally takes one line (python3 -m http.server 8000), and a tunnel service such as Pinggy (ssh -p 443 -R0:localhost:8000 free.pinggy.io -T) exposes it over HTTPS so the URL can be added as a custom repository in the F-Droid app — a way to verify that metadata, icon assets and signing configurations are handled correctly by the 2.0 client.

Why it matters

F-Droid has served as the primary open-source alternative to the Play Store on Android for over a decade, and the 2.0 rewrite addresses the maintainability risk of an aging codebase: a modern stack, a cleaner interface and background updates make the client easier to sustain and contribute to. Whether that investment pays off now depends less on code than on how Google implements the "advanced flow". If it genuinely lets experienced users sideload safely, the collision is manageable; if it turns exclusionary, a large share of F-Droid's catalog becomes hard to install on certified devices in the affected countries, and the deeper question — whether open-source app distribution can survive identity-gated platforms — becomes urgent. The dev.to article points to F-Droid's community forums and the official Android developer documentation as the places to watch as the policy matures.