F-Droid 2.0 Ships Six Days Before Google's Sideloading Lockdown. Here's What Developers Need to Know

F-Droid 2.0 hit #1 on Hacker News with 1,000+ points. The UI rewrite is nice. The timing is the real story.

Google starts enforcing Android developer verification on September 30, 2026. F-Droid shipped 2.0 on September 24. Six days. Let's talk about both.

What actually shipped

F-Droid 2.0 is a ground-up client rewrite, per the official announcement:

• Kotlin + Jetpack Compose, Material-aligned. The old Java codebase is gone.
• Three tabs: Discover, Search, My Apps. Settings and Nearby Swap moved to the top bar.
• Better search: indexes descriptions, categories and translations, adds CJK support, remembers recent queries.
• Combinable filters by category, device compatibility and anti-features.
• Auto-updates on by default, using Android's pre-approval install API.
• Android 7+ only. Android 6 is dropped.
• Independent security audit by the Open Technology Fund's Security Lab, after 14 test releases and 1+ year of work.
• Tor support simplified to proxy settings. The "wipe apps on panic" feature was removed as too costly to maintain.

Rollout is gradual over the coming weeks.

The HN thread wasn't all praise. Bulk update now needs per-app clicks, which people call a regression. And some alternative clients (Droid-ify, NeoStore) still consume the older index-v1, which is SHA1-signed, while official infrastructure has moved to index-v2.

The part that matters: developer verification

Google's rule: on certified Android devices, only apps registered to an identity-verified developer can be installed. Sideloads included.

Enforcement starts September 30 in Brazil, Indonesia, Singapore and Thailand, with global expansion planned for 2027. Three paths exist, as summarized by Pinggy:

1. Full distribution: verify your identity, register your package name with APKs signed by your key.
2. Limited distribution: email-based, capped at 20 devices, for hobbyists and students.
3. Advanced flow: a promised path for experienced users to sideload unregistered apps "with extra safeguards". Details still vague.

ADB installs are explicitly carved out. Custom ROMs and users outside the four countries aren't hit yet.

Why F-Droid is uniquely exposed

Most stores distribute your APK, signed by you. F-Droid builds from source and signs with its own key for the bulk of its catalog. Forum estimates put that at roughly 85% of apps.

Verification ties a package name to a developer's signing key. F-Droid's key isn't the developer's key. So for those apps you'd need a coordination mechanism between thousands of independent maintainers and F-Droid that does not exist yet.

Reproducible builds are the clean answer, since F-Droid could then ship the developer-signed APK. But reproducible-build coverage is only partial today.

What to do if you ship on F-Droid

• Check your reproducible-build status and push toward it. It's the only path where your key stays on the artifact.
• Register your package name in Google's system if you're in an affected region, even if you never touch Play.
• Watch the advanced flow spec. It decides whether power users can still install your app.
• Keep your applicationId and signing setup stable. Don't change them mid-transition.

My take

A better client doesn't fix a distribution-model problem. F-Droid 2.0 is a solid engineering win: audited, modern stack, sane UX. But the question for the next twelve months isn't the UI. It's whether an open, build-from-source store can coexist with an OS that wants every APK tied to a verified identity.

September 30 is the first real test. Four countries this time, everywhere in 2027.

Sources: F-Droid announcement, Pinggy, Android Authority, Hacker News thread.