Afam’s experience in tech publishing dates back to 2018, when he worked for Make Tech Easier. Over the years, he has built a reputation for publishing high-quality guides, reviews, tips, and explainer articles, covering Windows, Linux, and open source tools. His work has been featured on top websites, including Technical Ustad, Windows Report, Guiding Tech, Alphr, and Next of Windows.
He holds a first degree in Computer Science and is a strong advocate for data privacy and security, with several tips, videos, and tutorials on the subject published on the Fuzo Tech YouTube channel.
When he is not working, he loves to spend time with his family, cycling, or tending to his garden.
Ubuntu was one of the first Linux distros I tried and liked, so I naturally chose Snap, its “native” universal package. It was only recently, when I tried Flatpak, that I realized some of the tiny issues I always considered system problems were triggered by Snap’s sandboxing. Now I’ve used Flatpak enough to know it’s generally a better option.
The frustration
Snap started getting in my way
Snap runs fine in the background, and you generally expect updates to queue properly and the apps you need to be available in the store. The problem with specific apps like Spotify is the combination of snapd’s always-on daemon and queued refreshes, which can cause the app to launch into a “pending refresh” state. This is often reflected as a brief delay.
This specific issue seems absent in some other apps that ship as Snaps, like VS Code. However, there are other issues. With Firefox, for instance, video playback is sometimes choppy, and you do not get smooth scrolling. Snap’s confinement blocks proper GPU access by default, which can cause choppy video and unsmooth scrolling.
But for some reason, I have taken Spotify’s latency personally. It’s a bad mix of snapd’s background overhead, strict confinement, and an app that needs a clean, direct line to your audio system. Since the Snap Store is exclusively Canonical’s, there’s no flexibility in sourcing. Unlike native packages, where distro repositories are only the starting point.
Flatpak felt lighter right away
Fewer things getting in the way
Flatpak didn’t deliver instant speed boosts or flashy features, but it handled the basics without getting in the way. I control when updates are applied, which means that when I open an app, I don’t have to wait for a refresh to apply, and in the background, there isn’t an always-on daemon meddling.
It offers a healthy number of curated, trustworthy options that include most of the apps I need. Thanks to Flatseal, I can tweak what an individual app does without touching system-wide settings.
When compared side by side, Flatpak has a subtle edge with tiny improvements that actually count when it matters.
|
Feature |
Snap |
Flatpak |
|---|---|---|
|
Store openness |
Single, Canonical-controlled |
Flathub + additional remotes |
|
Background process |
snapd always running |
No persistent daemon |
|
Update control |
Automatic, queued |
User-controlled |
|
Theme integration |
Partial, often broken |
Improved, but still incomplete |
|
CLI experience |
snap run app |
flatpak run org.app.Name (verbose) |
Snap’s mounting clutter
You should brace yourself for the results if you run lsblk on a system that has Snaps installed. If you have ten apps, you get at least ten loop entries. This is because each Snap mounts a compressed SquashFS image as a loop device. It results in several loop entries that crowd the block device list, and the GNOME Disks utility ends up cluttered.
This is an intentional part of Snap design that aids atomic updates and strong isolation. However, it does this at the cost of a crowded system that can’t be read easily at a glance.
Flatpak uses OSTree for repo distribution and shared runtimes, mounting them via fuse-overlayfs rather than loop devices. In this case, several apps use the same deduplicated library pool. Since individual private environments are not mounted, this approach produces a filesystem that’s cleaner and easier to audit.
Flatpak has its own problems
But I preferred these over Snap’s
Sandboxing on Flatpak may occasionally trip up certain apps that require deep system access. I’ve observed this with VS Codium and GTK themes don’t have the most seamless implementation.
But the big difference is that these issues in Flatpak are usually visible and can be fixed. When issues appear, you can identify the cause and fix it—often by adjusting permissions with Flatseal. This is a contrast with Snap where the delays feel invisible. You are more likely to blame it on the system rather than on Snap. The system seems to work against you. So what Flatpak did that made the difference was giving you control.
The switch was also seamless. Flatpak has a straightforward installation, and enabling Flathub is quite easy. I easily migrated apps like Spotify. However, the one challenge was with certain packages like ubuntu-advantage-tools that silently reinstall snapd. If you do not know there is a possibility of this happening, you may think you have totally left Snap, even when it’s still present.
Not a verdict — a decision framework
It’s important to note that all I’ve done with Snap is demote it. It’s still a part of my system. For several of my daily apps, I prefer Flatpak; however, I keep certain system-level tools as Snaps. They simply belong there. One isn’t always superior; the best tool is the one that fits a specific job.
This is how I decide what works:
|
Scenario |
Best choice |
|---|---|
|
Daily desktop apps (Spotify, GIMP, Inkscape) |
Flatpak |
|
Ubuntu system tools (core utilities, LXD) |
Snap |
|
Firefox / Thunderbird on Ubuntu |
Either — both are upstream-maintained |
|
Apps needing strict permission tuning |
Flatpak + Flatseal |
|
Server daemons or background services |
Snap |
|
Maximum compatibility across distros |
Flatpak |
What I realized is that the more I have understood Linux package managers, the more I have moved apps to Flatpak.





