The Future of Flatpak

Original Article ↗ Hacker News Discussion ↗

Original goals and evolving use cases

  • Flatpak was designed for cross-distro, GUI desktop apps; people now also use it on immutable and embedded systems, sometimes without GUIs.
  • Several commenters see it as ideal for “big, messy” desktop apps (e.g., OBS, browsers) without polluting the base system; others argue system-level tools (e.g., VPNs) belong in the distro.

Permissions and sandbox limitations

  • Major pain point: missing or coarse-grained permissions.
    • Tailscale and other tools needing virtual network interfaces can’t be cleanly packaged; workarounds (flatpak-spawn + polkit) largely defeat sandboxing.
    • Audio uses PulseAudio semantics even on PipeWire, so speaker access implies microphone access; no “output-only” permission.
    • Newer granular flags like --device=input are blocked by older Flatpak versions and Flathub policy, forcing overly broad device permissions.
  • Portals theoretically solve many UX/security issues (file pickers, global shortcuts), but many apps don’t use them, causing broken features and confusing permission errors.

Project health, governance, and Red Hat

  • Multiple comments highlight Flatpak’s slowdown: mostly maintenance and security fixes, with feature MRs languishing for lack of reviewers.
  • This is seen as contradictory to Red Hat’s RHEL 10 strategy of dropping many desktop apps and telling users to get them from Flathub. Several argue Red Hat should fund Flatpak development proportionally.
  • Concern is higher for Fedora Silverblue/Kinoite, which rely heavily on Flatpak, than for “classic” Fedora.

User experience and integration issues

  • Frequent complaints: wrong themes/cursors, broken drag-and-drop, flaky audio/controller support, terminal apps discouraged or rejected on Flathub, and difficult plugin/script installation.
  • Some users report Flatpak apps crashing more than distro or Windows equivalents; others say Flatpak works well for GUI apps they don’t want deeply integrated.
  • Disk usage is a recurring criticism: simple apps (Telegram, Signal) pulling ~1GB runtimes vs tens of MB for native packages.

Alternatives and competing models

  • Snaps: praised for better CLI support and server-side use, criticized for past slowness and AppArmor dependency; some now find them performant and reliable.
  • AppImage: liked for simplicity, portability, and easy backup, but lacks an official “store” and truly universal compatibility.
  • Traditional distro packaging (apt/dnf/pacman): many argue it remains superior in reliability and integration, but doesn’t scale across many distros and versions; leads to duplication and maintainer burnout.
  • NixOS users often prefer Flatpak for desktop apps because Nix expressions are heavy for fast-moving GUI software.

Deeper disagreements: security vs simplicity and who should package

  • Some want strong sandboxing and per-instance permissions (“each running instance gets its own capability set”); others resent complexity and lost convenience, especially for simple workflows like saving/opening attachments.
  • There’s a philosophical split:
    • One camp says distros should package everything (“union of users”); another says that’s unsustainable and app authors need a cross-distro path.
    • Some see Linux’s trust model and fragmentation as fundamentally at odds with modern sandboxing; others argue Flatpak is trying to solve permissions and distribution simultaneously and is overextended.

Future directions and uncertainty

  • Ideas floated include WebAssembly-based apps, stronger portal adoption, per-instance sandbox identities, or doubling down on immutable bases + Flatpak/Distrobox.
  • Several participants fear Flatpak stagnation will leave Linux with a half-finished, complex ecosystem: neither cleanly sandboxed like mobile OSes nor as straightforward as Windows/macOS binaries.