Flatpak Development Restarts with Fresh Energy and Clear Direction

After a difficult period, the Flatpak project regains stability and focus under new maintainers with the 1.17 pre-release, the first update in six months.

Red Hat’s Sebastian Wick has shared some interesting insights into Flatpak’s development following the 1.17 pre-release, an unstable version (the current stable is 1.16.1), marking the first update in six months and a strong return for this popular Linux sandboxing framework.

In his latest blog post titled “Flatpak Happenings,” Wick acknowledged that Flatpak had reached a stagnant phase earlier in 2025, with development slowing and open contributions piling up.

Fortunately, development has now restarted thanks to renewed efforts from long-time contributors along with new maintainers stepping up to review and merge code more actively. Now, the project has been reorganized, streamlined its review process, and reestablished an active development rhythm.

As a result, Flatpak 1.17 pre-release, which begins a new unstable series, intended to pave the way toward a stable release later this year, introduces a series of technical refinements and new capabilities designed to make it more reliable and easier to integrate across Linux distributions:

  • Up-to-date documentation: The libflatpak documentation has finally been refreshed after years of neglect, making it easier for developers to work with the platform.
  • Pre-installed app definitions: Distributions can now define which Flatpak applications should be automatically installed or removed. Projects such as Aurora and Bluefin are already utilizing this feature to integrate core Flathub apps into their systems.
  • Enhanced OCI support: Flatpak now supports pre-installing apps directly from OCI images and remotes, a key step for upcoming enterprise use in RHEL 10.
  • Updated permissions model: A backward-compatible permissions system enables applications to adopt newer, more restrictive permissions—such as access to gamepads or USB devices—without compromising compatibility on older systems. This also lays the groundwork for tighter integration with PipeWire.

Additionally, the broader Flatpak ecosystem is also advancing. The flatpak-builder tool has been updated, and Flathub has introduced improved license compliance checks.

At the same time, work continues on a new systemd-appd service that will help authenticate and manage running Flatpak instances, a component that provides a crucial foundation for future capabilities, including nested sandboxing, PipeWire-based media handling, and the phasing out of the aging D-Bus proxy.

New efforts are also underway to improve desktop integration. The XDG Intents specification aims to enable richer inter-app communication, including features such as deep-linking and thumbnail generation. Meanwhile, a new session save/restore Portal and significant backend refactoring in the Portals frontend simplify communication and reduce complexity across the board.

Finally, although some planned changes didn’t make it into this pre-release, Wick confirmed that another unstable version is expected soon, followed by a stable release before the end of 2025.

Bobby Borisov

Bobby Borisov

Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.

8 Comments

  1. AlexLitter

    Total NIH useless Red Hat project reintroducing middle-age bundled package management that most of us fleed from Windows .exe/.msi.
    They’re pushing the agenda hard via millions poured into marketing paid trolls and an army of bots, to make you believe the community is behind it, yet once past the trolls, you see that it’s an empty void made of Red Hat employees mostly.
    Despite all the money to extinguish, discredit or deface the competition, Flatpak has not been widely adopted. Because it’s a terrible package manager of another era (that most Linux users actively decided to put behind), and because most people don’t care about sandboxing one bit.
    Plus, now that Red Hat toxicity to the FOSS world has been exposed, even less so. Flatpak has this extremely negative aura, and that’s probably why they’re trying to breathe new life into the failing project.
    It’s a desperate attempt to push at all cost something most people don’t need and won’t adopt. Red Hat doing what they do best, trying to promote in-house half-assed garbage that 2 self-made computer nerds have already done better or will in a competing project…

    1. LibsOfTech

      Who are these “2 self-made computer nerds have already done better or will in a competing project…”? Tell us.

    2. TW

      2 self-made computer nerds have already done better or will in a competing project…

      Could you tell me the name of that project? I’m curious, thanks.

  2. Micah

    Awesome to see! I would love to see a way forward for an official effort to work with companies/developers to bring their apps to Flatpak. Obviously not a hard thing with OSS but apps Like DaVinci Resolve would be SO MUCH better as a Flatpak

  3. Rick

    I had no idea the project was struggling. I use both snaps and flatpaks and both seem really fast on my cheap intel n100. I have been using less flatpaks and more snaps lately. Canonical has done a amazing job with snaps and I do not understand the complaints by the few when my cpu seems likes it almost doing nothing even when running a plex snap server 24/7 and using it for others things at same time. I’m going on 2 years with my mini n100 running 24/7 only rebooting one a week for updates.

    1. AlexLitter

      There are no real complaints about it. It’s just Red Hat paying trolls and bots to discredit and ideally extinguish the competition (while the opposite is rarely true) in their evil way.
      So, what they do is they pour a lot of money into making people believe the community-driven narrative around their projects, while in reality most contributions are made through Red Hat e-mails, and they’re not one bit more community-followed than competing projects. Then all the kool-aid drinkers, themselves (employees) or their paid trolls or mass-engineered bots start talking negative about the competing projects that have been doing their own thing without bothering anyone, and public opinion starts talking negative of Canonical, or XLibre, or any project representing a threat to NIH Red Hat projects that attempt at controlling and locking Linux to their benefit.
      Their followers are indoctrinated to the point they have absolutely no clue why they do so, but they’ve been deeply ingrained the idea and they just perpetuate it with zero critical thinking.

      That’s what Red Hat does on a massive scale. It’s the most toxic company in the Linux world, I’m talking Microsoft-level toxic.

      sudo apt purge flatpak && sudo apt-mark hold flatpak

      or

      sudo pacman -Rns flatpak
      cosmic-edit /etc/pacman.conf | and add flatpak to the IgnoreGrp

      is what you want in my opinion for a healthy system.

      1. Addicted

        No problem with Snaps?

        Even setting aside the fact that the most basic technical problems such as the incredibly slow loading of applications was only fixed within the last couple of years, snaps are filled with all sorts of non-technical licensing issues which is why no one other than Canonical is using that technology.

        There are legitimate issues with Flatpak but when your response is snaps are better (rather than suggesting rpm/pacman/apt instead) it’s clear you’re just a canonical booster/RH hater.

        It’s so weird to see the Microsoft/Apple corporate fanboism enter the Linux space.

  4. Anonymous

    Can’t wait

Leave a Reply

Your email address will not be published. Required fields are marked *