F-Droid's Progress and What's Coming in 2025

Original Article ↗ Hacker News Discussion ↗

Overall sentiment

  • Many commenters see F-Droid as crucial for software freedom and sanity on mobile.
  • Others appreciate it but use it sparingly, mostly as a complement to Google Play.
  • Enthusiasm is tempered by recurring complaints about UX, app discovery, and submission friction.

New capabilities: PWAs and iOS

  • PWAs are now supported as packages and this is welcomed, but:
    • People question how to meaningfully audit or communicate server-side data collection for PWAs.
    • There’s debate over how much logic/storage PWAs keep on-device vs server-side.
  • iOS apps via F-Droid are discussed in the context of EU alternative app stores.
    • This requires Apple account login, which some say undermines privacy motivations.
    • Feasibility and ecosystem details remain unclear.

Client app, UI, and updates

  • Longstanding frustration about buggy or awkward update flows, especially:
    • Update entries stuck in “Downloading.”
    • Poor usability on Android TV devices.
  • Others say stability and automatic updates have improved recently, especially with newer clients.
  • Several alternative clients (Droidify, NeoStore, F-Droid Basic, etc.) are recommended as:
    • More modern.
    • Less buggy.
    • Better at using Android’s newer background update APIs.
  • There is a notable issue that the Play Store sometimes “claims” apps installed from F-Droid.

App submission and documentation

  • First-time publishers report:
    • CI pipelines failing with poor error feedback.
    • Conflicting instructions between docs, templates, and community advice.
    • Slow or inconsistent support via community channels.
  • Some point to a simpler “Submission Queue” route, but this is easy to miss.
  • There’s agreement that onboarding docs and processes need consolidation and modernization.

Discovery, ratings, and project quality

  • Strong demand for:
    • Download counters or install metrics.
    • Better sort/filter options beyond “alphabetical” and “recently updated.”
  • Concerns:
    • F-Droid is full of half-baked or dead projects with no clear way to filter them out.
    • “Recently updated” can be gamed via meaningless version bumps.
  • Privacy constraints limit features like user accounts and rich ratings, though some argue for minimal metrics that don’t add telemetry.
  • Users often work around this by:
    • Checking last update date, GitHub stars, and repo activity manually.

Open-source fragmentation and governance

  • Fragmentation (multiple F-Droid clients, forks in general) is seen as:
    • Both a strength (experimentation, different trade-offs) and a weakness (diluted effort).
  • An example from another project is used to illustrate how rigid maintainers can drive forks that later die, wasting energy.

App ecosystem and recommendations

  • Numerous popular apps are cited as F-Droid successes (maps, podcasts, password managers, firewalls, RSS, media, Termux, etc.).
  • Recommended usage patterns:
    • Some run almost all apps via F-Droid, with Play Store as a fallback.
    • Others invert this, only using F-Droid for a handful of key apps.
  • Missing pieces:
    • Random generation tools.
    • Banking, transport, and government apps (seen as out of scope for hobby devs).

Versioning and rollbacks

  • A serious pain point: inability to easily roll back to prior app versions without losing data.
    • Example: a VPN app update broke, maintainers rolled back in the repo, but affected users had no simple downgrade path and had to wait months for a fix.
  • Commenters argue F-Droid should support safe downgrades / version pinning to mitigate such issues.