Browse the docs

Can it be packaged?

Check these before writing anything. An app can be listed when:

  • Upstream publishes an official Linux build at a stable public URL, not behind a login: a tarball, zip, .deb, .rpm, AppImage or installer.
  • Its main feature works inside the sandbox. It doesn’t depend on a host toolchain or service the sandbox can’t reach, or on a capability Flatpak can’t grant.
  • It runs on the current runtime the rest of the catalog uses.
  • It may be downloaded and used, and has a legitimate purpose. Closed-source apps are welcome.
  • It isn’t already on Flathub from its own developer (unless the developer asks), and if a third party packages it there, that package is missing a feature, has fallen behind or has stopped working (below).

The toolkit doesn’t matter (Electron and Tauri apps are welcome), the licence doesn’t matter, and neither does how the app was written: an app is judged by what it does, not by whether someone calls it AI-made (listing policies).

Apps already on Flathub

  • The developer publishes it on Flathub themselves (the app is verified there, or upstream maintains the Flathub manifest): we don’t package it again. If the developer asks us to, we do; the developer decides about their own app.

  • A third party packages it on Flathub: we can package it when that package falls short:

    • it is missing or breaks a feature: Enpass on Flathub can’t verify the browser behind its extension, which ours does (how);
    • it has fallen far behind upstream, or no longer works at all.

    The reason goes in the PR, and the app’s description says how our package differs from the Flathub one.

  • An app already on FlatPark whose developer later publishes it on Flathub stays, unless the developer asks for it to be removed.

For agents

Checking

  • Flathub: search flathub.org by the app’s name, not a guessed id; ids differ more often than expected. Then:

    curl -s -o /dev/null -w '%{http_code}\n' https://flathub.org/api/v2/appstream/<id>   # 404 = not there
curl -s https://flathub.org/api/v2/verification/<id>/status                         # "verified": true = the developer's

    A Flathub manifest repository whose commits come from upstream’s maintainers counts as the developer’s own even without the badge.

  • The download: find the official one, on the vendor’s site or the project’s releases. A mirror, a personal account or a third-party repack doesn’t qualify.

  • What the binary needs: unpack it and read readelf -d on the main binary (choosing a format).

  • Upstream’s tracker: search its issues for Flatpak and Flathub. A maintainer’s earlier answer often names the real blocker.

What doesn’t work in the sandbox

These have stopped listings. When the main feature needs one of them, the app isn’t listed; when only a side feature does, the app can be, and its description says what doesn’t work.

  • A host toolchain or runtime as the main feature: an IDE that needs the host’s .NET SDK, a front end for host qemu, an R IDE whose engine must load the host’s R. A read-only grant of the host tree doesn’t help.
  • Capabilities: packet capture and VPNs need CAP_NET_RAW or CAP_NET_ADMIN, which Flatpak never grants. A proxy client’s TUN mode can’t work; its local proxy port can.
  • Its own sandbox, built on namespaces: Flatpak blocks the mount and namespace syscalls an app’s own bwrap or minijail needs, whatever the permissions. Chromium-based apps use zypak instead; others have to turn their sandbox off (closed-source only, declared) or do without the feature.
  • Directly managing the host: apps whose purpose is to change system settings, install system packages or control other apps’ processes. Their developers usually want them to run unconfined, and that is a reason not to list them.
  • An open-source app that needs code injected or files changed to work. The fix belongs upstream; it isn’t listed until then.

The app id

  • Use upstream’s own identifier when it has one: the id of its own Flatpak, or a Tauri app’s identifier in tauri.conf.json. Then our package and any upstream one are the same application, not two rival ones.
  • Otherwise reverse-DNS of the project’s home: io.github.<owner>.<App> for a GitHub project, the vendor’s domain for a company.
  • A rename is a new package. A Flatpak ref is keyed on the id, so users don’t move to a new id by themselves. Add the new id as its own directory and keep the old one until the new one is out, then de-list it. There is no automatic migration yet: users of the old id install the new one themselves, so say so in the old app’s last release note or the de-listing PR. An approval carries over; cite the original link in the new approvals row.
  • An id containing someone else’s trademark (com.youtube.…) is avoided even if upstream uses it; pick a neutral one.

Content and licences

  • Closed source is fine with policy.proprietary: true, as long as the licence allows downloading from the vendor for personal use.
  • Downloaders and streaming clients get a look at the service’s terms and copyright first.
  • Piracy, malware and trademark impersonation are never listed.

Edit this page on GitHub