Table of Contents
Flatpak, the cross-distro runtime that has been the de facto standard for shipping graphical applications to Linux for years, has long become a household name for Linux app distribution and installation. For good reason, too: Flatpak solves the problem of Linux being hard to target as a platform, approaching the problem in a way that looks similar to what Java did with the JVM: distributing a distro-specific runtime on top of which generic applications compiled against that runtime can be executed anywhere that runtime is installed.
Like all things, however, Flatpak is evolving. Today, we will be going over what GNOME Developer Sebastian Wick had to say about this situation at LAS 2025. Just as a disclaimer, the actual list is long, and the original talk, rightfully, makes a lot of assumptions in knowledge of low-level Linux desktop components. Instead, I will be cherry-picking the changes I find most important, and try to make a compelling case for why you should care. If you are interested in knowing more, go watch the talk after this!
Where are we now?
Before we start with future plans, though, we need to set the record straight on one thing: Flatpak is stable. For a long amount of time, that had not quite been the case, as Flatpak absolutely used to have several immediate and often deal-breaking issues during its infancy. Most crucially, things did not always “just work”: just a few years ago, lack of good integration with Freedesktop Portals and low-quality packages would make Flatpak packages frequently a worse experience than native. Security and reliability of packages was also questionable: there was no concept of “Verified developer” or checked, trusted package:and you mostly had to trust the maintainer, while you could more easily trust you distro's repositories.
Today, Flatpak is very much good enough for the vast majority of use cases. Most big Linux distributions ship it by default - Fedora, Debian, Linux Mint, Pop!_OS, openSUSE, etc. - and, most importantly, it is used in commercial production on Valve's Steam Deck console. On the latter, it proves to be especially useful, as it allows installing applications with persistence, even on top of SteamOS's immutable base.
Sadly, that does not mean it's perfect.
Flatpak still has several well-known pain points. The software development experience, installing IDEs and compiler toolchains through Flatpak, is still a challenge. Audio is still routed through the old PulseAudio, lessening the new improvements on low-latency pro audio when running inside the sandbox. Most importantly, though, the situation with GPU drivers is quite problematic: the bundled drivers are often too old, lacking bug fixes and performance improvements, if not outright lacking support for bleeding-edge GPU generations until after several months from a GPU launch.
All these reasons, and more, are still important blockers, that make it hard for everyone to migrate to Flatpak from native packages, especially when more specialized use-cases, proprietary or bleeding-edge GPU drivers, or pro audio, are involved in the equation.
It will be easier to pre-install and integrate Flatpaks on distros
One of the areas where Flatpak will see a lot of work is the pre-installation experience for distro packagers.
As it stands, integrating Flatpak packages on a Linux distro through the default, out-of-box experience, is still a challenge. Sure - you can pre-install the Flatpak runtime. You can even pre-install Flathub, or you can make it trivially easy to enable, by adding a prompt during the installation wizard or leaving a simple check available in your “App Store” application, but it ends there.
It is still not feasible to integrate Flatpaks with native packages in harmony in a fresh install, even though it would make a lot of sense. Just think about your web browser: it's one of the most critical pieces of software you have on your device. Would you not want to constantly be on a current version, having it automatically update in the background with no need to reboot to automatically apply patches, while running in a sandbox to limit the risk of rogue JS using a 0-day vulnerability to ruin your entire week?
If you look at Ubuntu, this is already a reality. Ubuntu does not use Flatpaks by default but, rather, Snaps, Canonical's in-house solution that is set to achieve a similar result. As you can see, on a nearly fresh installation of Ubuntu, several system pre-installed applications, including the browser, are already installed and sandboxed through Snap, rather than being installed as a native Debian package.
Currently, this is not feasible on Flatpak. The situation is especially scuffed in the very popular case where a distribution wants to add its own configuration to a default App. For example, think about Fedora's build of Firefox. The firefox you find pre-installed on a Fedora system is not configured in the same state Mozilla ships it. Several default settings have been changed, both to better integrate Firefox with the distribution, and to improve privacy by disabling and inhibiting telemetry. Fun fact: the Fedora start page is not only branding or cosmetic, but it is a solid privacy default to make sure no logs get sent out in the initial setup.
It's natural. Distro packagers do not merely want to ship an App pre-installed, they want it to integrate with the distribution itself. This has always been antithetical to Flatpak, making it unsuitable for pre-installed experiences.
This is changing soon. Eventually, Flatpak will allow distro packagers to easily ship Flatpaks as pre-installed applications, pre-configuring them according to a set of defaults decided either by the distribution or by an IT department in a corporate environment.
This feature is implemented, and the code is there: it's just waiting to be merged, but it's very, very close.
Flatpak will play nicer with OCI standards
Although Flatpak is a containerized environment, it works quite a bit differently than other containerized environments you may know.
For example, if you are a professional Software Engineer coming from the Linux server side, you will likely be familiar with Docker or Podman, the engine you use to deploy containerized applications. When you docker pull something, you are pulling an OCI image of something from a remote registry, like Docker Hub, Quay or SonarType Nexus, which acts as a repository. The container image you download from the registry follows the OCI (Open Container Initiative) spec, a protocol that standardizes how container images and bundles are crafted, in order for them to be used by any engine (Podman, Docker, Moby…) on any registry.
On the other hand, Flatpak containers are completely different. Instead of OCI spec, they use ostree, a system initially created to version binary updates in a Linux distribution, inspired by what Git does with source files. ostree is used throughout the entire Flatpak stack: both on the client, and on the repository.
While ostree is a great tool, sadly, it also comes with its own set of drawbacks. Firstly, it's an uncommon piece of technology, that requires its own non-standard tooling to operate. Hosting entire repos on it also comes with its own set of issues.
Work is undergoing to make Flatpak play nicer with traditional OSI tooling. There is support for importing OCI images from standard registries and importing them locally into the ostree repo. This also allows using standard OCI-compliant tooling.
The moonshot goal is to go the extra mile and make Flatpaks normal OCI images, buildable with normal OCI tooling, seamlessly.
Permissions get more fine-grained, but they are backwards-compatible
Flatpak has been improving its own permission model for a while, by allowing users to enable a more thorough set of permissions.
As with any migration, though, it is not completely painless: backwards-compatibility. For a while, packagers have needed to set up fallback permissions in their configuration to keep supporting old Flatpak versions. Better support for backward-compatibilty is coming, though, and it is much smoother.
Finally, moving directly to Pipewire!
The Linux world has moved from PulseAudio to Pipewire. It's a much better audio subsystem than Pulseaudio, in every way. It was also a very smooth transition from PulseAudio: most users did not notice a thing, while people who work with audio professionally have been able to leverage the power of Pipewire, from low-latency audio to complex routing between nodes.
On Flatpak, using Pipewire's PulseAudio compatibility layer rather than interacting with Pipewire directly keeps some nasty old problems from the PulseAudio era around. Namely, a big issue is that speakers and microphone are bundled together in Flatpak applications, so you can either get one or the other. This is a miss: for a secure, containerized environment, it would be ideal to, for example, be able to pass the sink for the speakers, but not the microphone, to an untrusted proprietary application. One of the best uses of Flatpak is to use it for installing proprietary, or generally untrusted software, and the best feature of its sandbox is the philosophy of assuming you can't trust an application until proven otherwise. This change would increase the extent of restrictions you could pose to a proprietary application, without needing to give up audio in general for that peace of mind.
Not to mention, of course, that a change like this would make the audio production experience significantly smoother when using a DAW installed as a Flatpak package. Right now, your DAW needs to run as a native process in order to leverage the features of the newer audio system.
There is a proposal to stop using PulseAudio within Flatpak, and embrace Pipewire fully. Of course, this change comes with no shortage of technical challenges as a dependency, including the likely need to define dedicated Freedesktop Portals for the purpose.
Better driver support
Currently, the GPU driver situation on Flatpak is good, but it can cause some undesirable consequences when dealing in some niche edge cases, like hardware or software that is either too old or too new. If you have ever tried to run an old, unmaintained graphical application on a system with a recent GPU in a Flatpak package, or if you have tried to getting hardware acceleration to work under Flatpak at any capacity on an old Nvidia-powered 2013 Retina MacBook Pro that refuses to expose the Intel iGPU to Linux for reasons I am still yet to comprehend, you know what I am talking about.
The current approach has its reason to exist. Since applications are often tied to specific library versions, the current approach boild down to shipping the entire user-space part of the GPU drivers with the Flatpak runtime. Applications are built against a specific version of each runtime, which is exactly the design decision that allows them to keep operating even long after they have been discontinued.
Unfortunately, it turned out that extending this level of caution to the GPU driver has caused more problems than it solves. Breakages deriving from Mesa upgrades are rare, while malfunction stemming from using an outdated Mesa version is much more common.
In fact, recent GPUs almost always require a recent version of mesa to play nice with the new hardware. This can be a problem when dealing with old, unmtaintained Flatpak applications: if their runtime is stuck on an old Mesa version, running that application on your newer hardware is going to be a challenge. It is not quite hopeless - there are things to be done, like pulling the mesa-git runtime bundle from Flathub-Beta and trying to force Flatpak to override the default graphical runtime with that one - but it's usually a pretty annoying process that comes with its caveats and far from guarantees success.
If you are part of the huge part of the population who happens to own a Nvidia GPU, it's a whole other can of worms. There are Flatpak runtimes that target specific Nvidia driver versions, but they must be matched with a compatible version installed on the host system, and it is not always a process as smooth and painless as one would hope.
An improvement idea that is floating around is to, basically, just take a step back and load the host drivers directly into the runtime, rather than shipping a specific version of the userspace drivers along with the application. Technically, it is possible: Valve's Linux runtime is pretty similar to Flatpak architecturally, and they solved this problem from its inception by using a library called libcapsule to load the natively installed host drivers into the Steam Runtime. This is the reason why it's significantly rarer that an old Steam game fails to launch on a new GPU, compared to the same scenario on Flatpak!
More portals!
Lastly, one of the main improvements in the works is creating currently missing Portals to solve problems that are now not solvable. Flatpak relies almost entirely on Freedesktop Portals - oftentimes, when something is not doable in Flatpak, that means it is not doable with Portals.
There are lots of ideas floating around for new portals, ranging from password auto-fill portals - similar to the AutoFill application permission on Android, which would finally allow us to have the same comfort using a password manager like Bitwarden on the desktop as we do on mobile - to Portals related to AI and speech synthesis.
Wrapping up
Through all these years, Flatpak has proved itself as a worthy standard for Linux application development. However, while the software is stable, it is far from stale. It makes total sense to watch this space: exciting things are in the works here.
