I’ve already filed this with the Flatpak project, but I want to raise it here because GNOME strongly promotes Flatpak as the preferred application model. That makes this a GNOME‑level UX concern, not just a Flatpak one.
Here’s the issue:
When I run flatpak update, Flatpak detects an available update and immediately asks whether I want to install it — without showing the installed version or the available version.
This creates a fundamentally broken decision point:
Flatpak asks “Do you want to update? (y/N)”
But the user has no version information to answer that question
The only correct response is N, or to abort the workflow
Then the user must run flatpak info to learn the version
And finally run flatpak update again
It’s the equivalent of a doctor saying:
“Do you want the treatment?”
“What is the treatment for?”
“I’m not telling you unless you ask me a different question in a different room.”
It’s absurd on its face.
This isn’t about commit philosophy or metadata purity. It’s about workflow logic — the system asks for consent before providing context. Why would GNOME endorse this?
GNOME emphasizes good UX, clarity, and user‑respecting design. But this workflow violates the most basic UX principle: don’t ask the user to make a decision without giving them the information required to make that decision.
Every major platform — Windows, macOS, iOS, Android, and traditional Linux package managers — shows the version delta before asking for confirmation. Flatpak already knows both values at the moment it detects the update. It simply doesn’t display them.
If GNOME is going to promote Flatpak as the primary application model, this kind of UX gap matters. It affects GNOME users directly.
I’m asking GNOME to advocate for a fix, or at least acknowledge that this workflow is not aligned with GNOME’s own UX principles. Thanks for listening.
First, an update in Flatpak does not necessarily need an version number. It is good and encouraged practice to have an release in the Appstream file with any update of the Flatpak, which could then be displayed.
But AFAIK for Flatpak itself, it just is an change of which OSTree commit is used.
If Appstream data is available, you could display “Update from X.Y.1 to X.Y.2”. But if not, it could just be “Update from dedc6baca353 to f479f5d2075d”[1].
Second, one of the most important things to do are updates. You want security fixes applied so your system doesn’t has security issues. You want your bugs to be fixed on your system. And maintainers of software are really no fan of bug reports or feature request which are already resolved, but the user haven’t installed that update yet.
But the users are often slow to update, staying on old versions longer than necessary (just look at all people using an LTS for “stability”).
So, in this regard, you want to make an update process as straightforward as possible, so that the users has as few excuses to not update as possible. Which is why GNOME Software for example defaults to automatically updating Flatpaks.
I just used some random UUID’s for this. The numbers itself are not important, just the point they aren’t that useful. ↩︎
Thanks for the thoughtful reply. I want to clarify something important: this issue is not about whether Flatpak uses versions, commits, or Appstream metadata. It’s about the workflow sequence.
Flatpak asks the user to make a yes/no decision before showing the information needed to make that decision. That’s, to me, is a serious flaw.
Even if the only information available is a commit hash, the workflow should still be:
“You have commit A. Update available: commit B.” Then ask for confirmation.
Right now the workflow is:
“Do you want to update?”
“What update?”
“I won’t tell you unless you abort this workflow and run a different command.”
That’s the part that makes no sense.
Security and frictionless updates are important, but they don’t justify a decision loop where consent is requested before context is provided. Even automatic update systems show what changed after the fact. Flatpak shows nothing before or after unless the user goes hunting for it.
This isn’t about metadata purity — it’s about basic UX logic. Context must come before consent. And not telling user a version/hash/or anything else before you update creates a situation where the user CANNOT make an informed decision. That is just not right.
Flatpak is a third-party project, not a GNOME project, so this really isn’t the best place to discuss the usability of Flatpak command line user experience.
This would be a good place to discuss GNOME’s desktop integration on top of Flatpak, though. By default, GNOME actually install Flatpak updates without your consent, because updating is almost always the right choice for almost all users, and asking for consent would introduce pointless friction. GNOME Software automatically updates all installed Flatpak apps once per day. You can disable this by uninstalling GNOME Software or changing the Software Updates preference from Automatic to Manual:
If you choose to update manually, GNOME Software displays each app that will be updated, and the version it will be updated to. However, it unfortunately does not display the current installed version:
Also, the description for 100% of the updates that I see today is the same: “No update description available.” That could be changed by adding additional appstream metainfo, but almost nobody bothers to do so.
Thanks — you basically highlight the core issue even more clearly.
If GNOME Software:
does not show the currently installed version
and often cannot show the update description
and frequently displays “No update description available”
and relies on AppStream metadata that most apps don’t provide
…then the user still cannot make an informed decision about an update.
That means both the Flatpak CLI and GNOME Software share the same underlying flaw:
They ask the user to approve a change without providing the context needed to understand that change. This is the essence of my point.
Whether the missing information is:
the installed version
the new version
the delta
the description
or even a commit hash
…the result is the same: the user is being asked to consent without context.
Automatic updates are fine for users who want them, but when a user chooses to update manually — in the CLI or in GNOME Software — the workflow should still respect basic UX logic. Tell the person what is changing so that they can decide whether they want the change or not.
