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 have to open both apps and switch their windows.

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

1- It takes a lot of space. jUsT bUy a bIgGeR dRiVe --stfu I'm not going to spend money for you to waste it

1- a) Everyone assumes you're an American with 20Gbps symmetrical fiber optic. My internet can't handle 2+ Gb downloads for a fucking 50 Mb app bro

2- Duplicate graphics drivers. Particularly painful with Nvidia

3- It puts a lot of security work with distro library trees straight into the shitter

4- Horrendously designed system for CLI apps (flatpak run org.whocares.shit.app)

5- Filesystem isolation has many upsides for security but also it can cause some pain (definitely nitpicking)

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?

The worst part of flatpaks is that they don't get to see the actual path of files that they open. Instead, they get a /var/run/1000/blah proxy. The proxy is forgotten after you reboot, so any flatpak that memorized that path is holding a bunch of dead links.

• overly verbose way to launch them in terminal
• can sometimess not even respect your gtk/qt theming
• sandboxing/permission system can lead to you trying to figure out which directory you need to give access to when you want to save file if it wasn't preconfigured
• uses its own libraries and not system libraries, want to play the hit new AAA game with steam flatpak? get fucked it requires a mesa commit that was merged 8 hours a go and you're stuck on 23.0.4 and can't use the git release.

Flatpak probably has it's specific uses like trying to use one piece of proprietary software that you don't trust and don't want to give it too much access to your system, or most GUI software clients having an easy way to install Discord on your Steam Deck (no terminal usage, Linux is easy yay), but native packages 99% of the time work better.

Startup time and disk space.

It's great for user apps, gui apps, and sandboxing. It's terrible for cli apps, libraries, development, and integration.

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.

Some people don't like it because it uses a bit more storage and can start a bit slower, (I think) they can't be used for system packages, and I've also had some issues with theming

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 only take slightly more space than system 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)

No proper estimate of download size.

Yes. It is not pacman

• no OS level components
• duplicate libraries as some core apps (editor, filemanager, Desktop) cannot be flatpaks (yet?)
• old runtimes etc. dont force developers to keep them updated. Often thats because or 3rd party packagers though
• complicated packaging, I heard that the Flatpak builder is better for certain languages.
• theming issues I heard (on Fedora Kinoite Wayland it just works, and I can also force themes per app)
• bad permissions by default (best we have though)
• bad run commands (this could easily be fixed, and I have a script for it)

For OS components / packaging every part, Snaps may work, but for GUI apps they seem subpar and nobody really cares.

Nix may be way better for installing just anything compartimentalized, but there is no permission system (thats why packaging is easier).

But Flatpaks are really great overall, Bubblewrap, KDE Settings / Flatseal, Portals, official app support. Its really really important.

It ruins single source of truth for apps and their installed state. It hides installed state from standard enterprise tools.

the main drawbacks I see are related to the sandboxing of apps, e.g. that several firefox addons that I just, such as the KeePassXC connector don't work in flatpak packaged firefox, because they require native messaging support which is unavailable in flatpak. There is a three year old bug report on this at github, and an even older bug report in the Firefox bugzilla. Unfortunately, there seems to be no capacity to solve this or this is not a priority, although this problem affects quite a few users. I have similar issues with the Flatpak packages Nextcloud client: Do to the poor system integration, neither autostart works not integration with Nautilus or other file managers, unless you do some manual tinkering (which isn't particularly difficult, but with native packages it will just work™ out of the box.) These issues have been known for many years, yet there seems to be no activity to solve them.

Bloated and unnecessary if freeSW or openSW. That's what system shared libraries are for. If sandboxing is a thing, then firejail is availble, which can be combined with apparmor if looking for extra MAC security.

I’ve had my first downside with flatpak.

VSCode’s flatpak version won’t let you use certain packages because they’re installed on the system and flatpak is a sandbox with no access. You need to enable some stuff but I’m far too lazy to troubleshoot that shit.

I got the Snap version so I’m ready for the hate.

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's still a few edge cases that Flatpak is not great for. The Flatpak version of Kdenlive video editor can't see Whisper, which it uses to generate subtitles. The Appimage and native builds work flawlessly.

I'm assuming these problems will be addressed eventually but it takes time.

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

Yes, security

Endlessly reading on social media that is not a good from Linux "gurus". LOL

It's been great for me, but I wish it had a official gui for permissions management.

It is the default on atomic distros. And many people who got to know flatpaks use it as a default on traditional installs as well.

But there are still bugs and quirks with some apps. Not all apps have all the functionality as a traditional install. E.g. dolphin or terminals.

It is up and coming and gradually replacing traditional installs. You rarely find an app that you can't install via flathub.

There are theming issues with older flatpaks.

Edit:

I have no idea how to view logs in the terminal with flatpaks.

You can't easily run flatpaks by their common known names. You have to use the reverse flatpak name which is annoying and difficult.

As everything in life, yes, there is downside. Major downside is that it can occupy more space in your hd or ssd.

However I think the downsides are not that bad to justify all the hatred some guys have.

Flatpak positive sides are way more relevant then the downsides

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.

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.

I've used flatpak for a while because it's the default ob Fedoras GUI Software Center, but I've recently switched back to dnf and native packages where I can.

The thing is, that I have a shitty 500GB SSD with a shitty 50Mbit Internet connection (which is closer to 30Mbit because my house still has lead cables instead of copper). So downloading 300+ MB of libraries for a 2MB Program is just not feasible for me.

Flat pack install OBS? works awesome! Try to install plug in afterward not so much.

As a basic end-user I have not been too happy with my experience with flatpaks. I do appreciate that I can easily setup and start using it regardless of what distro I'm using. But based on standard usage using whatever default gui "app store" frontends that usually come with distros, it tends to be significantly slower than apt, for instance, and there seems to be connection problems to the repos pretty often as well.

I'm a little put off by the inconvenient command line and the mandatory bells and whistles (flathub is nice and all, but must it be baked into the main executable rather than having the package manager as an optional thing on top?).

So far, AppImage just looks superior to me. Works without installing a runtime into my system, no need to become root and integrate an app into a system-wide managed package repository, I can just run it.

Others have mentioned disk usage and desktop integration. There is some truth to them, but shared runtimes keeps disk uasge down (although worse than native apps). Desktop launchers now search /var/lib/flatpak/exports/share/applications by default, but I'm still having issues with themes in one or two niche apps.

Trust is the big one. The benefit of your distro's packages is that they are maintained by a limited number of maintainers. Flatpaks have a much, much larger number of maintainers, which is where sandboxing comes in. Flathub now marks apps with lax permissions as "potentially unsafe", which is a huge step in communicating this to the average user.

Most desktop apps can get away with having next to no access, as long as they support the appropriate XDG desktop portals.

Ultimately, your mileage will vary, as there are many classes of application which are ill-suited to being sandboxed. Program launchers, programming languages, IDEs, file managers are a few.

What could be wrong with random foreign executables in your system?

One of the use cases I would like to have used Flatpak for is Visual Studio Code. Unfortunately, I found the isolation to be too onerous for developer needs. Take the Rust compiler toolchain. There's no way to access that from VSCode. There are ways to add on tools to the VSCode environment, but that feels like a kludge when I already have everything installed and set up. And if the toolchain isn't available for Flatpak, tough luck. Other features just simply don't work. I eventually switched to using the Ubuntu builds from the VSCode developers.

Edit: The Rust compiler toolchain can be added onto Flatpak because there is a packaged version of the toolchain, but it's not the host environment's version. Other tools like the fish shell might be entirely unavailable.

The biggest downside is that it's only for distributing applications with a graphical user interface. Command line utilities still need another method of distribution.