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.