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)

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.

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.

• 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.

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.

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

No proper estimate of download size.

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

For me, the question is why I should add an extra layer of complexity. If the things I use already work well using apt, and if most things are bundled in the default distro install, then my life is already good.

This all depends on your software needs, if course. Some people are using a lot of new stuff, so the above setup leads to annoying situations.

• 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.

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.

Yes. It is not pacman

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.

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)

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.

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.

They dont integrate well into your system like they should, (theming, bookmarks, storage, etc), and to fix that you gotta do some work arounds that should be done automatically

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.

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 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.

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.

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.

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

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.

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.

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

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.

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

I don't use Flatpak much, but I rarely see issues. Sometimes I see minor things like themes not quite being right, but its never been bad enough for me to spend the time to fix it.

I suppose another downside is the need to have the base runtime packages, so it could take more disk space if each app uses a different one. In practice apps will share runtimes though.