Linux users can argue about almost anything, but few topics trigger stronger reactions than package formats. Mention Snap in a Linux forum, and chances are someone will complain about startup speed, Canonical’s control, or automatic updates. Mention Flatpak, and the same people often respond much more positively.
At first glance, this seems strange.
Both Snap and Flatpak were created to solve similar problems. They package applications with their dependencies, work across multiple Linux distributions, improve security through sandboxing, and make software distribution easier for developers.

From a distance, they look like two roads leading to the same destination. Yet many Linux users dislike Snaps while embracing Flatpaks.
The reason isn’t simply technical.
It is a combination of performance, philosophy, user experience, and trust.
The problem snap was trying to solve!
Before criticizing Snap, it’s important to understand why it exists.
Linux distributions traditionally package software differently. An application available on Ubuntu might not be available on Fedora, Arch Linux, or openSUSE in the same form. Developers often had to maintain multiple packages or rely on distribution maintainers.
Snap was Canonical’s answer.
The idea was ambitious:
- One package format for all Linux distributions.
- Automatic updates.
- Better security isolation.
- Easier software publishing for developers.
- Consistent behavior across systems.
On paper, these goals made perfect sense.
In fact, many users today enjoy software that would be difficult to distribute widely without technologies like Snap or Flatpak. The problem is not what Snap tried to achieve. The problem is how many users experienced it.
First impressions matter.
For many Linux users, the first encounter with Snap wasn’t pleasant.
A common complaint involved application startup times.
Early versions of Snap-packaged applications often took noticeably longer to launch compared to traditional packages.
When a browser takes several seconds longer to open, users notice. When every launch reminds users that something feels slower than before, frustration builds.
Even though Snap performance has improved significantly over the years, first impressions are difficult to erase. Many users formed their opinions during those early experiences and never looked back.
Meanwhile, Flatpak arrived without carrying the same reputation.
Fair or not, Snap started the race with a trust deficit.
The “Canonical” factor.
Another major reason has little to do with performance.
Linux users often value decentralization and openness. They generally prefer ecosystems where multiple organizations can participate equally.
Snap is developed by Canonical, the company behind Ubuntu.
While Snap itself is open source, the official Snap Store infrastructure is controlled by Canonical. There is no widely adopted independent store ecosystem comparable to Flatpak’s repository model.
For some users, this feels too centralized.
The concern isn’t necessarily that Canonical is doing something wrong. Rather, many Linux enthusiasts dislike the idea of a single company controlling a critical distribution channel.
Flatpak, on the other hand, feels more community-driven.
The popular Flathub repository is widely seen as a shared community resource rather than a vendor-controlled platform. That perception matters.
Technology decisions are often emotional as much as technical.
Automatic updates: Helpful or annoying?
One of Snap’s most controversial features is automatic updates.
From a security perspective, automatic updates make sense. Users receive bug fixes and security patches without having to remember anything.
However, Linux users tend to value control.
Many want to decide:
- When updates happen.
- Which packages update.
- Whether an update should be delayed.
- What changes are installed.
When software updates itself without explicit approval, some users feel like they are losing ownership of their systems.
This creates an interesting paradox.
A feature that improves security for average users can simultaneously irritate power users.
Flatpak also supports updates, but many users feel they have more control over the process. Whether that perception is entirely accurate is less important than the fact that the perception exists.
Integration issues hurt snap’s reputation.
Desktop integration has also played a role.
Over the years, users reported various issues involving:
- File access permissions.
- Theme inconsistencies.
- Clipboard behavior.
- Hardware access limitations.
- Integration with desktop environments.
Many of these issues were eventually fixed or improved.
The challenge is that users remember problems longer than solutions.
If someone encounters three annoying issues in a week, they may conclude that the entire platform is flawed.
Flatpak has experienced its own share of bugs and integration challenges, but it often avoided becoming the symbol of those frustrations.
Snap became the target.
Flatpak focused on desktop applications.
One reason Flatpak gained popularity is that it concentrated heavily on desktop software. For desktop Linux users, Flatpak often feels purpose-built.
Applications such as media players, image editors, communication tools, and development software are commonly available through Flathub.
The installation experience is usually straightforward.
Users often find what they need, install it, and move on.
Snap, by contrast, tries to serve multiple worlds simultaneously:
- Desktop applications
- Cloud workloads
- IoT devices
- Embedded systems
- Servers
This broader vision is impressive but can make the platform feel less focused from a desktop user’s perspective.
Community perception became self-reinforcing.
Perhaps the biggest reason Snap receives criticism today is momentum.
Once a technology develops a negative reputation, every issue reinforces the narrative.
A Flatpak bug is often treated as an isolated bug.
A Snap bug is often treated as proof that Snap is bad.
This creates a feedback loop.
New users read complaints before they try Snap.
When they encounter even a minor inconvenience, it confirms what they already expected.
The cycle continues.
Community perception can become stronger than technical reality.
Is the hate still justified?
The answer depends on what someone means by “hate.”
Many criticisms of early Snap releases were valid.
Users experienced slower launches, awkward desktop integration, and limited control over updates. These were real concerns, not imagined ones.
However, modern Snap is not identical to the Snap of several years ago.
- Performance has improved.
- Compatibility has improved.
- The overall experience has improved.
At the same time, some philosophical objections remain. Users who dislike centralized infrastructure or prefer maximum control are unlikely to change their minds regardless of technical improvements.
Those concerns are about values rather than benchmarks.
The reality: Both formats solve real problems.
The Linux ecosystem benefits from having both Snap and Flatpak.
Flatpak excels at desktop application distribution and has earned strong community support.
Snap remains useful for cross-distribution software delivery, enterprise deployments, IoT devices, and applications that benefit from its packaging model.
Most users do not need to choose sides.
If an application is available as a Flatpak and works well, use it.
If a Snap package is maintained better or updated more frequently, use that instead.
The best package format is often the one that gives you the software you need with the fewest headaches.
Final thoughts.
The debate between Snap and Flatpak is often framed as a battle between good and bad technology. In reality, it is closer to a clash of expectations.
Many users dislike Snap because of historical performance issues, centralized infrastructure, forced updates, and early user experience problems. Flatpak earned goodwill by focusing on desktop applications, offering a community-driven ecosystem, and arriving without the same baggage.
Yet the story is more nuanced than internet discussions often suggest.
Snap is not universally bad, and Flatpak is not universally perfect.
Both formats represent different approaches to solving Linux software distribution challenges. Understanding those differences helps users make informed choices instead of simply repeating community opinions.
In the end, the healthiest approach is not loyalty to a package format. It is choosing the tool that works best for your needs.
Leave a Reply