I don't get why people in this thread are conflating Flatpak with different ways to do desktop UI. Even if your app is a single self-contained binary, it can benefit from Flatpak. Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike. That has not much to do with what you use to write UI. Flatpak can't be entirely replaced by self-contained binaries.
> I don't get why people in this thread are conflating Flatpak with different ways to do desktop UI.
Flatpak is often used as a solution for creating OS-agnostic distribution packages for applications, by bundling dependencies. This is an example of a solution that provides a standalone binary, obviating the need for the extra complexity of Flatpak.
> Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike.
These all point out the problems with Flatpak.
Runtime sandboxing is unrelated to packaging and distribution, and having Flatpak do both of these things amounts to poor separation of concerns: how do I use a Flatpak package when I don't want sandboxing, and how do I sandbox a non-Flatpak app? The combinatorics of the use cases involved require multiple simultaneous solutions to both package management and sandboxing, which undermines Flatpak's aspiration to be a universal solution.
The attempt to unify the package format, apart from being a prime example of XKCD 927, also highlights the complexity of package management as a concept. If you're going to bundle dependencies anyway, why bother with building a packaging solution to include dynamically linked libraries? Why not release static builds that minimize the need for packaging in the first place?
The idea of Flatpak being easier on developers masks the attempt to shift packaging responsibility to app devs in the first place -- the traditional approach is that developers just work on their app, and the distro maintainers are the ones who package and distribute it. So this approach is actually extra work for devs.
> That has not much to do with what you use to write UI.
It's less about the UI and more about the self-contained nature of the executables generated by the engine.
