For the better part of a decade, Linux desktop users have been caught in a three-way tug-of-war over how software should be distributed. Flatpak, Snap, and AppImage — three competing universal packaging formats — each promised to solve the same fundamental problem: making it easy to install and run applications across any Linux distribution without dependency headaches. Now, according to fresh data and shifting industry momentum, the debate appears to have reached a resolution. Sort of.
The numbers tell a clear story. Flatpak has won the popularity contest, and it isn’t particularly close.
As MakeUseOf reported, Flathub — the primary repository for Flatpak applications — surpassed one billion cumulative downloads in 2024 and now hosts more than 3,000 applications. That figure has continued climbing. The platform’s growth trajectory has been steep, driven by adoption from major distributions including Fedora, Linux Mint, elementary OS, and the Steam Deck’s SteamOS. Canonical’s Snap Store, by contrast, has struggled to build comparable enthusiasm outside Ubuntu’s own user base, while AppImage remains a niche tool favored by developers who want maximum portability without any store infrastructure at all.
But reducing this to a simple scoreboard misses what’s actually happening beneath the surface — a story about corporate strategy, community governance, and the philosophical tensions that have defined open-source software development for thirty years.
To understand why Flatpak emerged dominant, you have to understand what each format actually does differently. All three aim to bundle an application with its dependencies into a self-contained package that runs on any Linux distribution. The execution, though, diverges sharply.
Snap, developed and controlled by Canonical, uses a centralized backend store that only Canonical operates. Every Snap package must go through Canonical’s servers. The company has maintained this as a deliberate architectural choice — the server-side component of the Snap Store remains proprietary, meaning no one else can stand up a competing Snap repository. For enterprise deployments, Canonical argues this provides a single trusted source. For the open-source community, it feels like a chokepoint. And that perception has had consequences.
Linux Mint, one of the most popular desktop distributions in the world, famously blocked Snap packages by default starting in 2020. The Mint team’s objection was pointed: they didn’t want Canonical’s proprietary store infrastructure embedded in their operating system without users’ explicit consent. That decision sent a signal. Other distributions followed suit in spirit if not in identical policy, gravitating toward Flatpak as the community-governed alternative.
Flatpak’s architecture is decentralized by design. Anyone can host a Flatpak repository. Flathub happens to be the dominant one, but it’s not the only option, and its governance structure is transparent. The Flathub project operates as an independent entity, not a subsidiary of any single corporation. Red Hat contributed significantly to Flatpak’s early development, but the project has broadened its contributor base. This matters to distribution maintainers who are wary of ceding control to a single vendor — a recurring theme in Linux politics.
AppImage takes an entirely different approach. No store. No daemon. No system integration beyond what the user explicitly sets up. An AppImage is a single executable file: download it, mark it executable, run it. That’s it. The simplicity is appealing to a certain kind of user and developer. It’s the closest thing Linux has to macOS’s drag-and-drop .app bundles. But that simplicity comes with trade-offs — no automatic updates by default, no centralized security review, and no sandboxing unless the developer builds it in separately.
As MakeUseOf’s analysis noted, AppImage’s lack of a centralized distribution mechanism has limited its reach. Developers who ship AppImages must handle hosting and update infrastructure themselves. For small open-source projects, that’s often fine. For larger applications trying to reach millions of users, it’s a logistical burden that Flathub absorbs automatically.
The Steam Deck changed everything. Or rather, it confirmed what was already happening.
When Valve shipped its handheld gaming PC in 2022 running SteamOS — a customized Arch Linux distribution — it chose Flatpak as the preferred method for installing non-Steam software. Millions of devices. Millions of users who had never thought about Linux packaging formats suddenly had Flatpak running on their hardware. The Steam Deck didn’t just validate Flatpak technically; it created an enormous new install base overnight. Developers who wanted their software available on the Deck published to Flathub. The flywheel spun faster.
Canonical hasn’t conceded. The company continues to integrate Snap deeply into Ubuntu, which remains the most widely used Linux distribution overall. Ubuntu’s software center defaults to Snap packages. Firefox on Ubuntu ships as a Snap. So do other core applications. Canonical’s argument for Snap has always centered on server and IoT use cases as much as the desktop — Snap’s confinement model and automatic update mechanism are designed for environments where administrators want tight control over deployed software. In that context, the centralized store isn’t a bug; it’s a feature.
But on the desktop, the market has spoken. A recent survey cited by MakeUseOf found that among Linux desktop users, Flatpak usage significantly outpaces Snap. The gap has widened as more distributions ship with Flatpak support out of the box.
Performance has been a persistent criticism of all three formats, though the specifics differ. Snap packages have long been criticized for slow startup times. The issue stems from Snap’s use of SquashFS compression — each Snap must be decompressed and mounted at launch. Canonical has made improvements over successive releases, but the perception of sluggishness has proven sticky. Flatpak’s startup performance is generally better, though both formats consume more disk space than traditional native packages because they bundle dependencies rather than sharing system libraries.
AppImage sidesteps some of these concerns by being lighter weight, but introduces others. Without sandboxing, AppImages run with whatever permissions the user has. That’s a security model from the 1990s. Flatpak and Snap both implement sandboxing through different mechanisms — Flatpak uses Bubblewrap and portal APIs; Snap uses AppArmor profiles. Neither sandbox is perfect. Both have had vulnerabilities discovered and patched. But both represent a meaningful improvement over running arbitrary downloaded binaries with full user permissions.
The developer experience tilts toward Flatpak as well. Flathub’s submission process, while not without friction, has become increasingly streamlined. The project introduced verified publisher badges, giving users confidence that an application on Flathub actually comes from its official developer. Major applications — GIMP, LibreOffice, OBS Studio, Discord, Slack — all maintain official Flatpak builds on Flathub. The repository has become, in practice, the closest thing Linux has to a universal app store.
There’s an irony here. The Linux community spent years resisting the concept of an app store, viewing it as an Apple or Google-style walled garden. Flathub succeeded precisely because it isn’t walled — anyone can publish, anyone can host an alternative repository, and the entire stack is open source. It’s an app store built on open-source principles, and that combination turns out to be what the community was willing to accept.
So is the debate truly settled? Not entirely. Snap isn’t going anywhere as long as Ubuntu exists, and Ubuntu isn’t going anywhere. AppImage continues to serve developers who want the simplest possible distribution mechanism without external dependencies. Some applications ship in all three formats simultaneously, letting users choose.
But the momentum is unmistakable. Flatpak has achieved what the other two haven’t: broad adoption across distributions, a thriving centralized-but-open repository, growing developer buy-in, and a massive consumer install base through the Steam Deck. The packaging war isn’t over in the sense that the losers have surrendered. It’s over in the sense that the market has picked a default.
For Linux on the desktop — a phrase that has been both aspiration and punchline for two decades — this matters more than it might seem. One of the persistent barriers to mainstream Linux adoption has been software availability. Users switching from Windows or macOS expect to find applications easily and install them without reading forum threads about dependency resolution. Flathub provides that experience. Not perfectly. But well enough.
The remaining challenges are real. Flatpak’s disk space overhead is nontrivial. Theming inconsistencies between Flatpak applications and native desktop environments persist. Some system-level applications don’t work well in sandboxed containers. And the question of who governs Flathub long-term — and how it sustains itself financially — remains open. The project has explored revenue-sharing models and donation mechanisms, but hasn’t settled on a permanent funding structure.
None of these problems are existential. They’re engineering and governance challenges, the kind that successful open-source projects solve iteratively. What matters is that the fragmentation that once defined Linux software distribution is consolidating around a single format that most of the community finds acceptable. That’s not nothing. For an ecosystem historically defined by its inability to agree on anything — from init systems to text editors — it might be the most remarkable consensus in years.
The great Linux packaging war produced no treaty, no formal surrender. Just a billion downloads and a market that quietly made its choice.
WebProNews is an iEntry Publication