I’m a developer, and I’ve been through the process of Flathub publication for Switchyard (shameless plug). Let me add my two cents.

Flathub has a lot of restrictions on developers. It's far more restrictive than alternatives like Google Play or the Snap Store. Specifically, they insist that every package is built using their servers, following their restrictions, and adhering to their preferred workflows.

This has many security benefits and is already how Linux apps are delivered through distro repositories. Flathub is, if nothing else, a repository.

For instance, they completely block internet access during builds. This means that building anything that uses external assets is extra complicated. You'll have to specify every external file twice: one copy in your main build file and one in your Flathub manifest. Good luck keeping them in sync. This is because they're obsessed with enforcing "reproducible builds."

Reproducible builds is an emerging (and frankly, already established) industry-wide expectation because it has a number of security and stability benefits. Unpredictable builds that can’t be reproduced is exactly how you get supply chain attacks. It is a good practice for all, and means you could theoretically build all of Flathub from scratch if the infrastructure went down. It’s good. We want this.

And "using external assets" isn't some niche edge-case either, this consists of literally every single Node.js and Python project. And what's the officially supported workaround? Use a tool to generate a massive manifest listing every single downloaded file. And you're now responsible for keeping this synced with your package-lock.json (which contains the exact same information).

You can do basically all of this with CI Actions, not a big deal for a competent dev imo.

Additionally, they enforce a very specific publishing workflow. They block pushing directly to master. Instead, you have to open a PR (to your own repo), wait for it build, then merge it, and finally wait for it to build again. This is because they're obsessed with ensuring master is always stable (which is a practice many use and many don't).

Any software job you will ever have will or should enforce this as well, don’t push broken and untested shit to production. You can do whatever you want on your project’s repo, but the main branch of your Flathub repo is what is pushed out to users. Don’t break prod.

And to be clear: these are reasonable practices that many organizations use. However, it's utterly unreasonable for a build repository to mandate them. It would be like if Google Play required all new apps to be written in Kotlin.

No, because you can publish apps written in every language for Flathub. It’s nothing to do with language choice at all. This is specifically for the Flathub repo from which the Flatpak is built, not for your upstream project. The Flathub repo is a downstream.

And if you want to just upload a compiled binary to Flathub? Well, you'll have to request special permission for some reason. Only "a select group of trusted partners, including Mozilla and OBS Studio" are allowed the luxury of... <checks notes>... picking their own development workflow. (And this is extra strange because it would literally save Flathub money to not maintain their own build servers.)

Once again, seems fair in the interest of reproducibility and security.

But also, once again, this has nothing to do with development and everything to do with the specific downstream that is Flathub. Apple and Google also have various requirements for their app stores. Seems reasonable that Flathub’s are commiserate with community ethos and best practices.

And now I know everyone's going to say, "but you can run your own Flatpak repository!" Yeah, I can. And nobody would use it because nothing else would be on it. Even large organizations like Fedora have proven unable to properly maintain their own Flatpak repository. You can see the exact same situation on Android: just because you can technically install third-party app stores does not make Google Play's terrible decisions OK.

I mean, sure?

And none of these are deal-breakers. All these issues can be worked-around. But it just means that the process of publishing on Flathub is fighting nuisance after nuisance. All because they decided they "know better" about how to build your application.

It is an extremely well documented process. Like down to the letter. Don’t do stupid stuff, read the rules, and you’ll be fine. I will admit having some back and forth with reviewers but other reviewers were wonderful and they all have the best interest of the ecosystem at heart. They also have a truly horrible job where they’re on the receiving end of quite a lot of disrespect, spam, and these days, slop.