Yes, I love it and don’t get me wrong but there are many downsides and they all result from poor planning and/or bad decisions around how flatpak was built. Here are a few:

• Poor integration with the system: sometimes works against you and completely bypasses your system instead of integrating with it / using its features better. To me it seems more like the higher levels are missing pieces to facilitate communication between applications (be it protocols, code or documentation) and sometimes it is as simple as configuration;
• Overhead, you’ll obviously end up with a bunch of copies of the same libraries and whatnot for different applications;
• No reasonable way to use it / install applications offline. This can become a serious pain point if you’re required to work in air gapped systems or you simply want to level of conservation for the future - it doesn’t seem reasonable at all to have to depend on some repository system that might gone at some point. Note that they don’t provide effective ways to mirror the entire repository / host it locally nor to download some kind of installable package for what you’re looking for;
• A community that is usually more interested in beating around the bush than actually fixing what’s wrong. Eg. a password manager (KeePassXC) and a browser (Firefox/Ungoogled) both installed via flatpak can’t communicate with each other because developers seem to be more interested in pointing fingers on GitHub than fixing the issue.

Flatpak acts as a restrictive sandbox experience that is mostly about “let’s block things and we don’t care about anything else”. I don’t think it’s reasonable to have situations like applications that aren’t picking the system theme / font without the user doing a bunch of links or installing more copies of whatever you already have. Flatpak in general was a good ideia, but the system integration execution is a shame.

Problem I have with Flatpak is their way of naming packages which makes them very akward to run in a WM. That’s basically the only reason why I haven’t used Flatpak since I switched to WMs, pacman and AUR also work really well so there isn’t even a reason to use something else.

I believe it’s the packaging process. It favors the standatd procedure of builds, and does not take account of various build systems (Seems C-centered). Seems this is why many apps end up providing AppImages instead.

Why isn’t this just the default?

One may notice that for every new method, the old ways stay around, possibly forever. It is not the default because there were things that worked prior to flatpak. The distros that from before flatpak have likely added the capability, but won’t likely change their default for another decade, or more.

There is some drawback. The main one : app can’t communicate with each other.

Example firefox and his extension keepass. As keepass can’t communicate with firefox, you will have to open both apps and switch their windows.

You can use flatseal to manage communicatiom between app but that’s not an easy process and may prove a security issue if you don’t understand the technical jargon.

I think its biggest weakness is also its biggest strength: isolation. Sometimes desktop integration doesn’t work quite right. For instance, the 1password browser extension can’t integrate with the desktop app when you use flatpak firefox.

Take a look at this site that goes into the details of the shortcomings of Flatpak, its from 2020 but I’m sure some of this is relevant still

Flatpak usually ships very outdated drivers.

I’ve been in the support channel for yuzu linux, and you would not believe all the issues people have with games freezing, etc that are instantly fixed by using the appimage instead of the flatpak.

Also flatpaks are non-xdg compliant, since it creates the useless ~/.var directory. And they have said over and over that they won’t fix that. So fuck them.

Not to mention all the issues people have with their theming and integration into the system.

Appimages are just simpler and better, the other day I was thinking how many issues would be fixed if Steam shipped as an appimage.

• It would allow for shipping a patch glibc with EAC
• It would allow for moving all the nonsense that steam puts in the home user dir, since appimages support a portable home.
• It would allow for shipping the 32bit libraries instead of having to install them system wide.

And depending on how you go about, appimages will even take less disk space than flatpaks or native packages even though you don’t get shared libraries with those, because they are compressed which reduces their size significantly.

Like for example the LibreWolf appimage is 110MiB while a the native package for librewolf 300MiB. Same with LibreOffice, the appimage is 300MiB while the native package is 600 MiB.

It also makes it easier to downgrade if you run into an issue, like I had to had an older appimage of ferdium because the latest version is affected by an electron bug that broke its zoom functionality.

All that was said here, plus sometimes they don’t work. I’ve reported a bug where the kdenlive flatpak version doesn’t render titles or fades - and that’s on Debian Testing, Arch, and Asahi Fedora. Native version works perfectly, but forces me to download an untidy amount of KDE stuff on my gnome installs ; flatpak would’ve been a cool solution to that.

I am yet to report another where Ardour nukes pipewire, at least on Asahi, but on Arch it was misbehaving also. Native, distro-provided version works perfectly.

I don’t trust flatpak because no one single publisher can test every possible config, and I’m afraid distros become “lazy” and stop packaging native versions of stuff since it’s a lot of work.

No proper estimate of download size.

Yes, security

IMO yes but it might not be an issue for you, flatpaks work like windows standalone executables where each app brings all their dependencies with them, the advantage is the insane stability that method provides, the downside is the huge size the app will ultimately take, flatpaks are compressed and they don’t really bring all their dependencies with them (because they can share runtimes) but the gist of it is a flatpak is usually much heavier than a system (.deb .rpm .PKG) package.

If you are ok with tweaking I recommend nix pkgs as they work on any distro and take slightly more space than regular packages. I have a terrible connection and low disk space, flatpaks aren’t something I can use on the long run.

Oh and if you’re wondering flatpak >>>> snap > appimages (IMO)

For me it’s lacking in user friendliness. Go easy on the downvotes if I’m doing it the hard way.

• Flatpaks aren’t really single-executables. You have to use to the flatpak command to run them.
• I can’t just say flatpak run firefox, I have to use the full app-id which could be quite long.

Yes, I could make this simpler with scripts or aliases but how hard would it have been for Flatpak to automatically do this for me?

It’s HUGE. That’s the biggest downside for me. I’m always use a deb/native package first because they are way smaller.

Startup time and disk space.