We have replaced Buildbot with a custom service, and we hope you haven't noticed.
<a href="https://github.com/flathub-infra/vorarbeiter" target="_blank" rel="noopener noreferrer">Vorarbeiter</a> is a German word for "foreman" and a living proof of
my school-related trauma. The new service is a middleman between GitHub and
GitHub Actions. It has been happily humming since April 21st, and largely does what
Buildbot did: builds apps, with a sprinkle of publishing logic.
While what happens under the hood is solid, there is no UI yet. Flathub bot
will still inform developers about build status for their pull requests, but
there is little visibility of what happens post-merge.
Additionally, Vorarbeiter no longer allows to manually publish, cancel or
delete builds. The publishing happens every hour regardless of the age of the
build. The previous 3-hour-long delay was too conservative, and barely anyone
was giving a final test for a post-merge builds. Similarly, cancelling builds
doesn't seem as necessary as before. GitHub Actions runners are ephemeral and
new commits on the same branch or pull request will automatically cancel the
previous in-progress build.
Last but not least, because of limitations of the free GitHub Actions runners,
some apps are designated as large builds. Large builds take place on machines
provisioned in AWS, boasting faster CPUs and larger disks to accommodate
heavier requirements.
While large builds do not incur costs per se thanks to the generous <a href="https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/" target="_blank" rel="noopener noreferrer">AWS
credits for open source projects program</a>, we still want to be mindful of
how much credits we are spending, which is why we don't run large runners all
the time. This is possible thanks to <a href="https://runs-on.com/" target="_blank" rel="noopener noreferrer">RunsOn</a>, which handles all the
magic for us. It receives pipeline events from GitHub and provisions new
machines automatically within seconds, and tears them down the moment the build
is finished. This is completely invisible to developers, but is both faster and
more cost-effective, even if we were to pay the bill ourselves.
There is still more work to be done. I want to improve observability of the new
service to make sure we can have automatic alerts when we have an abnormal build
error rate or unprocessed publishing queue. In fact, we already notify
maintainers and Flathub admins when a build triggered on the master branch
failed, but there is potential to be more proactive here.
The unsolved challenge so far is caching. Every new pipeline re-downloads
Flatpak runtimes, SDKs, and source code needed to build the app. Ideally, we
should cache at least the runtimes, but with runners being ephemeral, we should
also attempt to implement a distributed solution for ccache to reduce build
times.
Given <a href="https://docs.flathub.org/blog/flathub-build-infrastructure-revamp" target="_blank" rel="noopener noreferrer">the challenging circumstances</a>, this is more than good enough,
though! If you encounter any issues with the new workflow, don't hesitate to
<a href="https://github.com/flathub-infra/vorarbeiter/issues" target="_blank" rel="noopener noreferrer">open an issue</a> in the project's GitHub repository.

We have replaced Buildbot with a custom service, and we hope you haven't noticed.

Vorarbeiter is here

With thousands of apps and billions of downloads, Flathub has a responsibility to help ensure the safety of our millions of active users. We take this responsibility very seriously with a layered, in-depth approach including sandboxing, permissions, transparency, policy, human review, automation, reproducibility, auditability, verification, and user interface.

Flathub Safety: A Layered Approach from Source to User

With apps made for different form factors, it can be hard to find what works for your specific device. For example, we know it can be a bit difficult to find great apps that are actually designed to be used on a mobile phone or tablet. To help solve this, we’re introducing a new collection: On the Go.
<a href="https://flathub.org/apps/collection/mobile/" target="_blank" rel="noopener noreferrer"><img decoding="async" loading="lazy" alt="On the go: Apps for your Linux phones and tablets" src="https://docs.flathub.org/assets/images/banner-5b926fa8d591a0a78d6d7d91182221e7.png#gh-light-mode-only" width="2800" height="888" class="img_ev3q"> <img decoding="async" loading="lazy" alt="On the go: Apps for your Linux phones and tablets" src="https://docs.flathub.org/assets/images/banner-dark-aa945d7c5bee552d43977019f5be740d.png#gh-dark-mode-only" width="2800" height="888" class="img_ev3q"></a>
As the premier source of apps for Linux, Flathub serves a wide range of people across a huge variety of hardware: from ultra powerful developer workstations to thin and light tablets; from handheld gaming consoles to a growing number of mobile phones. Generally any app on Flathub will work on a desktop or laptop with a large display, keyboard, and mouse or trackpad. However, devices with only touch input and smaller screen sizes have more constraints.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="revealing-the-app-ecosystem">Revealing the App Ecosystem<a href="https://docs.flathub.org/blog/on-the-go-linux-mobile-collection#revealing-the-app-ecosystem" class="hash-link" aria-label="Direct link to Revealing the App Ecosystem" title="Direct link to Revealing the App Ecosystem">​</a></h2>
Using <a href="https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#device-support" target="_blank" rel="noopener noreferrer">existing data</a> and open standards, we’re now highlighting apps on Flathub that report as being designed to work on these mobile form factors. This new <a href="https://flathub.org/apps/collection/mobile/" target="_blank" rel="noopener noreferrer">On the Go collection</a> uses existing device support data submitted by app developers in their MetaInfo, the same spec that is used to build those app’s listings for Flathub and other app store clients. The collection is featured on the Flathub.org home page for all devices.
<img decoding="async" loading="lazy" alt="Foliate app adapting across a desktop, tablet, and phone" src="https://docs.flathub.org/assets/images/foliate-adaptive-ac2537f4b445b3a31753a0a066949c04.png" width="1000" height="600" class="img_ev3q">
Many of these apps are adaptive across screen sizes and input methods; you might be surprised to know that your favorite app on your desktop will also work great on a Linux phone, tablet, or Steam Deck’s touch screen. We aim to help reveal just how rich and well-rounded the app ecosystem already is for these devices—and to give app developers another place for their apps to shine and be discovered.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="developers-its-up-to-you">Developers: It’s Up to You<a href="https://docs.flathub.org/blog/on-the-go-linux-mobile-collection#developers-its-up-to-you" class="hash-link" aria-label="Direct link to Developers: It’s Up to You" title="Direct link to Developers: It’s Up to You">​</a></h2>
As of this writing there are over 150 apps in the collection, but we expect there are cases where app developers have not provided the requisite device support data.
If you’re the creator of an app that should work well on mobile form factors but isn’t featured in the collection, take a minute to double-check the <a href="https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#device-support" target="_blank" rel="noopener noreferrer">documentation</a> and your own apps’s MetaInfo to ensure it’s accurate. Device support data can also be used by native app store clients across form factors to determine what apps are displayed or how they are ranked, so it’s a good idea to ensure it’s up to date regardless of what your app supports.

With apps made for different form factors, it can be hard to find what works for your specific device. For example, we know it can be a bit difficult to find great apps that are actually designed to be used on a mobile phone or tablet. To help solve this, we’re introducing a new collection: On the Go.

On the Go: Making it Easier to Find Linux Apps for Phones & Tablets

There is a storm coming and we are re-architecting our build infrastructure.
Buildbot has never been designed to do what Flathub needs: taking arbitrary inputs like application IDs and dynamically creating new pipelines. However, there's no misuse one cannot achieve if something is being configured in A Real Programming Language, and so, back in 2019, <a href="https://blogs.gnome.org/alexl/" target="_blank" rel="noopener noreferrer">Alex Larsson</a> piled a bunch of hacks so we could have not only dynamic configuration based on Flathub organization in GitHub, but also some custom views displaying latest builds.
Fast-forward to 2025, these hacks no longer work with the latest release of Buildbot, rendering our soft fork stuck on a version from 2021. For whatever reason, updating GitHub CI status stopped to work well, allowing people to merge untested code changes. It also requires periodical restarts because it grinds to a halt for no particular reason, dropping new builds in the meantime. The worst offense: I never liked it.
Interlude: Equinix Metal née Packet has been sponsoring our heavy-lifting servers doing actual building for the past 5 years. Unfortunately, they are shutting down, meaning we need to move out by the end of April 2025.
This perfect storm means we need to effectively re-architecture build infrastructure from scratch.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="webhook-proxy">webhook-proxy<a href="https://docs.flathub.org/blog/flathub-build-infrastructure-revamp#webhook-proxy" class="hash-link" aria-label="Direct link to webhook-proxy" title="Direct link to webhook-proxy">​</a></h2>
Let's start from improving Buildbot reliability where it falls short. While GitHub shows delivery status of webhook events, and even provides a button to trigger another attempt, there's no public API exposing this data.
As there's no way I'm fixing Buildbot itself, I decided we need a middleman which will take care of redelivering if Buildbot's webhook endpoint responded with non-200 response.
<a href="https://github.com/flathub-infra/webhook-proxy" target="_blank" rel="noopener noreferrer">webhook-proxy</a> is a simple Python service which accepts payloads from GitHub, marks new pull requests as pending CI, then forwards unchanged events to Buildbot. Should Buildbot have a hiccup, it will open a circuit breaker and retry with exponential back off until it eventually succeeds.
It ain't much, but it's honest work.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="justpak">justpak<a href="https://docs.flathub.org/blog/flathub-build-infrastructure-revamp#justpak" class="hash-link" aria-label="Direct link to justpak" title="Direct link to justpak">​</a></h2>
An important piece of the future Buildbot replacement is being agnostic of its CI/CD implementation. The idea is to provide only a business logic service, while actual building is delegated elsewhere. As such, it requires some relatively generic tool to execute tasks instead of maintaining two or more pipeline definitions for whatever is the CI/CD solution of the decade.
After evaluating modern <code>make</code> replacements, I settled on <a href="https://just.systems/" target="_blank" rel="noopener noreferrer">just</a>. It seems simple enough for executing external commands, and has a nifty way of defining recipes with a specific shebang from the get-go, so it's all a single file even when using a mix of Python and Bash.
I copied all build steps done by the Buildbot workers to specific recipes to have a single entry point. Then I started doing back flips with GitHub Actions to see if this is a viable way in the first place; turns out it is, although not without some hurdles.
While GitHub Actions have a native way of executing all steps inside a Docker container, the host running said container is full of bloat and barely has any free disk space. <a href="https://bbhtt.space/about/" target="_blank" rel="noopener noreferrer">bbhtt</a> suggested how to remove unneeded files, which also meant each build step is prefixed with <code>docker run</code> as we want to re-use existing <a href="https://github.com/flathub-infra/flatpak-builder-lint" target="_blank" rel="noopener noreferrer">flatpak-builder-lint</a> image instead of meddling with Ubuntu.
Then I went to GNOME GitLab to implement identical pipeline because I have no mouth and I must write YAML. GitLab has its set of quirks but after configuring its runners to stop dropping job output and kindly asking GitLab to stop unconditionally kill jobs whose logs exceeded a certain size, we've got the answer: it will blend!
<table><thead><tr><th>Application ID</th><th>Buildbot</th><th>GitHub Actions</th><th>GNOME GitLab</th></tr></thead><tbody><tr><td>Vim</td><td>4m 29s</td><td>3m 03s</td><td>1m 46s</td></tr><tr><td>Fractal</td><td>28m 29s</td><td>31m 09s</td><td>23m 37s</td></tr><tr><td>QGIS</td><td>123m 00s</td><td>198m 00s</td><td>124m 43s</td></tr><tr><td>Ungoogled Chromium</td><td>75m 28s</td><td>timed out at 6h</td><td>177m 29s</td></tr></tbody></table>
Apps on the smaller size can be safely built on GitHub Actions, but anything larger like Chromium, LibreOffice or KDE runtime will need some special treatment by being routed to GNOME GItLab. It's still not as fast as existing infrastructure is, but it will no longer be existing in a quarter, so there's nothing to be complaining about here. As both GitHub Actions and GitLab CI allow triggering workflows through API, it will be also easy to integrate with some external system.
The work-in-progress repo can be found <a href="https://github.com/barthalion/justpak" target="_blank" rel="noopener noreferrer">here</a>.
I was initially panicking about replacing aarch64 runners, but it turns out GitHub is providing that since September 2024. Build times are in line with the table above, meaning we are only worried about outliers. I have submitted Flathub to Works on Arm program, and if it gets accepted, we will handle that similarly to x86_64.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="the-rest-of-the-owl">The rest of the owl<a href="https://docs.flathub.org/blog/flathub-build-infrastructure-revamp#the-rest-of-the-owl" class="hash-link" aria-label="Direct link to The rest of the owl" title="Direct link to The rest of the owl">​</a></h2>
It's all cool and dandy, but the crucial part is still missing: a service encapsulating business logic. Buildbot encapsulates starting new builds, figuring out where they should go (Is it a test build? Is it a beta build?), retries for failed builds and managing publishing, all of that with a fancy UI.
There's no punchline here: I'm only starting the legwork to figure out which language and framework to use. If you would like to see something specific implemented, don't hesitate to request it <a href="https://github.com/flathub-infra/vorarbaiter/issues" target="_blank" rel="noopener noreferrer">here</a>.

There is a storm coming and we are re-architecting our build infrastructure.

What's next for Flathub build infrastructure

It's been a busy year, and our platform and developer community-building efforts are paying off. Let's take a look at what we've been up to over the last six months, and measure its effect.
At the beginning of the year we announced an incredible milestone for Flathub: <a href="https://docs.flathub.org/blog/over-one-million-active-users-and-growing">over one million active users</a>. But we didn't slow down; in February we <a href="https://docs.flathub.org/blog/fosdem-2024">attended FOSDEM</a>, then announced <a href="https://docs.flathub.org/blog/improved-build-validation">improved app moderation</a> and <a href="https://docs.flathub.org/blog/introducing-app-brand-colors">app brand colors</a> in preparation for some new features. Those efforts ultimately launched with <a href="https://floss.social/@flathub/112315662449987878" target="_blank" rel="noopener noreferrer">the new homepage and featured app banners</a> in April.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="milestones">Milestones<a href="https://docs.flathub.org/blog/2-billion-downloads-2024#milestones" class="hash-link" aria-label="Direct link to Milestones" title="Direct link to Milestones">​</a></h2>
<img decoding="async" loading="lazy" alt="Flathub: 70% of top apps verified, 100+ curated quality apps, 4 million active users, 2 billion downloads" src="https://docs.flathub.org/assets/images/milestones-c133cfc68c2aaa2cd7b8ceb2e8e085d3.png" width="1920" height="1080" class="img_ev3q">
We're back with some new milestones thanks to the continued growth of Flathub as an app store and the incredible work of both our largely volunteer team and our growing app developer community:
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="70-of-the-most-popular-apps-are-verified">70% of the most popular apps are verified<a href="https://docs.flathub.org/blog/2-billion-downloads-2024#70-of-the-most-popular-apps-are-verified" class="hash-link" aria-label="Direct link to 70% of the most popular apps are verified" title="Direct link to 70% of the most popular apps are verified">​</a></h3>
Over <a href="https://flathub.org/apps/collection/verified/" target="_blank" rel="noopener noreferrer">1,000 apps</a> have been verified by their developers on Flathub, including 70% of the <a href="https://flathub.org/apps/collection/popular/1" target="_blank" rel="noopener noreferrer">top 30 most popular apps</a>. Developers of verified apps are ultimately in charge of their own app listings, and their updates are delivered directly to Flathub users while passing our automated testing and human review of things like permission changes.
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="100-curated-quality-apps">100+ curated quality apps<a href="https://docs.flathub.org/blog/2-billion-downloads-2024#100-curated-quality-apps" class="hash-link" aria-label="Direct link to 100+ curated quality apps" title="Direct link to 100+ curated quality apps">​</a></h3>
Over 100 apps are now passing our quality guidelines that include checks like icon contrast on both light and dark backgrounds, quality screenshots, and consistent app naming and descriptions so users get a better experience browsing Flathub. These guidelines are what enable us to curate and display visually appealing and consistent banners on the new home page, for example.
This means that between late February and July, the developers of over 100 apps went out of their way to improve—and sometimes make significant changes to—their apps' metadata to get ready for these new guidelines and features on Flathub. We're proud of these developers who have gone above and beyond, and we look forward to even more apps opting in over time.
Developers, if you'd like to see your app featured on the home page, please ensure you are following these guidelines! We've <a href="https://fosstodon.org/@bragefuglseth/112430463664651417" target="_blank" rel="noopener noreferrer">heard from app developers</a> that getting your app featured not only gives a bump in downloads, but can also bring an increase in contributions to your project if it's open source.
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="4-million-active-users">4 million active users<a href="https://docs.flathub.org/blog/2-billion-downloads-2024#4-million-active-users" class="hash-link" aria-label="Direct link to 4 million active users" title="Direct link to 4 million active users">​</a></h3>
Six months ago we passed one million active users based on a simple if conservative estimate of updates to a common runtime version we had served. Using that same methodology, we now estimate we have over 4 million active users!
As a reminder, this data is publicly available and anyone can check our work. In fact, I personally would love if we could work with a volunteer from the community to automate this statistic so we don't have to do manual collation each time. If you're interested, check out <a href="https://github.com/flathub-infra/website/issues/2945" target="_blank" rel="noopener noreferrer">this GitHub issue</a>.
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="over-2-billion-downloads">Over 2 billion downloads<a href="https://docs.flathub.org/blog/2-billion-downloads-2024#over-2-billion-downloads" class="hash-link" aria-label="Direct link to Over 2 billion downloads" title="Direct link to Over 2 billion downloads">​</a></h3>
Those users have been busy, too: to date we have served over two billion downloads of different apps to people using different Linux flavors all around the world. This is a huge community of people trusting Flathub as their source of apps for Linux.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="thank-you">Thank you!<a href="https://docs.flathub.org/blog/2-billion-downloads-2024#thank-you" class="hash-link" aria-label="Direct link to Thank you!" title="Direct link to Thank you!">​</a></h2>
Thank you to our download-happy community of users who have put their trust in Flathub as their source of apps on Linux. Thank you to all of the developers of those apps, and in particular those developers who have chosen to follow the quality guidelines to help make Flathub a more consistent and engaging space. And thank you to every contributor to Flathub itself whether you are someone who fixed a typo in the developer documentation, helped translate the store, contributed mockups and design work, or spent countless hours keeping everything running smoothly.
As a grassroots effort, we wouldn't have become the Linux app store without each and every one of you. ❤️

It's been a busy year, and our platform and developer community-building efforts are paying off. Let's take a look at what we've been up to over the last six months, and measure its effect.

2 Billion Downloads & Other Milestones from 2024 So Far

Starting next week, June 17th, the linter will no longer allow enabling
automatic merge for pull requests created by flatpak-external-data-checker,
unless the app uses an extra-data source or has been added to the exceptions list.
The verified apps utilizing <code>automerge-flathubbot-prs</code> before May 28th have
been grandfathered and no explicit action is required from the maintainers. If
your app does not meet these criteria, you can still
<a href="https://docs.flathub.org/docs/for-app-authors/linter/#exceptions" target="_blank" rel="noopener noreferrer">request an exception</a> by creating a pull request to the
flatpak-builder-lint repository. Exception requests will be judged on a
case-by-case basis on providing valid reasons.
The <code>automerge-flathubbot-prs</code> feature has been introduced back in 2019 to
reduce maintenance overhead of applications dependent on non-redistributable
data. If <a href="https://docs.flatpak.org/en/latest/module-sources.html#extra-data" target="_blank" rel="noopener noreferrer">an extra-data source</a> used by the app disappears because
of an update, the automation would ensure that it is still possible to install
the app, without requiring manual intervention from the maintainers.
Over time, the feature has started to be misused as a general purpose
automation for publishing updates without proper testing. This has led to a
number of issues where apps became broken overnight, which could have been
easily prevented if the update was tested before merging.

Starting next week, June 17th, the linter will no longer allow enabling

Linter breaking change: restricting automatic merge

We're gearing up to launch curated banners on the Flathub home page! However, before we can do that there's one more blocker: Banners need a background color for each app, and many apps don't provide this metadata yet. This is why today we're expanding our MetaInfo quality guidelines and quality checks on the website; If you haven't yet, please add these colors to your app's MetaInfo file using the <code>&lt;branding/&gt;</code> appstream tag, and read on to learn more about brand colors.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="what-are-brand-colors">What are brand colors?<a href="https://docs.flathub.org/blog/introducing-app-brand-colors#what-are-brand-colors" class="hash-link" aria-label="Direct link to What are brand colors?" title="Direct link to What are brand colors?">​</a></h2>
App brand colors are an easy and effective way for app developers to give their listing a bit more personality in app stores. In combination with the app icon and name, they allow setting a tone for the app without requiring a lot of extra work, unlike e.g. creating and maintaining additional image assets.
<img decoding="async" loading="lazy" alt="GNOME Software Explore view with brand colors on app banners" src="https://docs.flathub.org/assets/images/software-explore-d58dc692ba057248ae81947f54fc3ba4.png" width="1204" height="922" class="img_ev3q">
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="why-now">Why now?<a href="https://docs.flathub.org/blog/introducing-app-brand-colors#why-now" class="hash-link" aria-label="Direct link to Why now?" title="Direct link to Why now?">​</a></h2>
This idea was first implemented in elementary AppCenter, and later standardized as part of the <a href="https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-branding" target="_blank" rel="noopener noreferrer">AppStream specification</a>.
While it has been in AppStream itself <a href="https://github.com/ximion/appstream/issues/187" target="_blank" rel="noopener noreferrer">for a few years</a>, it was unfortunately not possible for Flathub's backend to pick it up until the recent <a href="https://docs.flathub.org/blog/improved-build-validation">port to libappstream</a>. This is why many apps are still not providing this metadata—even if it was available from the app side we were unable to display it until now.
<img decoding="async" loading="lazy" alt="elementary AppCenter with brand colors on app banners" src="https://docs.flathub.org/assets/images/appcenter-2a23f6901160f6f9b5f2b2c3a43976a8.png" width="2816" height="1790" class="img_ev3q">
Now that we can finally pick these colors up from AppStream MetaInfo files, we want to make use of them—and they are essential for the new banners.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="adding-brand-colors">Adding brand colors<a href="https://docs.flathub.org/blog/introducing-app-brand-colors#adding-brand-colors" class="hash-link" aria-label="Direct link to Adding brand colors" title="Direct link to Adding brand colors">​</a></h2>
Apps are expected to provide two different brand colors for light and dark. <a href="https://github.com/pika-backup/pika-backup/blob/8f2f04a1a27d2b04db48f7dbf26577009ff39be3/data/app.metainfo.xml.in#L44" target="_blank" rel="noopener noreferrer">Here's an example</a> of a MetaInfo file in the wild including brand colors.
This is the snippet you need to include in your MetaInfo file:
<div class="language-xml codeBlockContainer_Ckt0 theme-code-block" style="--prism-color:#393A34;--prism-background-color:#f6f8fa"><div class="codeBlockContent_QJqH"><pre tabindex="0" class="prism-code language-xml codeBlock_bY9V thin-scrollbar" style="color:#393A34;background-color:#f6f8fa"><code class="codeBlockLines_e6Vv">&lt;branding&gt; &lt;color type="primary" scheme_preference="light"&gt;#faa298&lt;/color&gt; &lt;color type="primary" scheme_preference="dark"&gt;#7f2c22&lt;/color&gt; &lt;/branding&gt; </code></pre></div></div>
In choosing the colors, try to make sure the colors work well in their respective context (e.g. don't use a light yellow for the dark color scheme), and look good as a background behind the app icon (e.g. avoid using exactly the same color to maintain contrast). In most cases it's recommended to pick a lighter tint of a main color from the icon for the light color scheme, and a darker shade for the dark color scheme. Alternatively you can also go with a complementary color that goes well with the icon's colors.
<img decoding="async" loading="lazy" alt="Three examples of good/bad brand colors" src="https://docs.flathub.org/assets/images/color-examples-b5812a4e182bb2cd38b8a1dffc401bb1.png" width="556" height="204" class="img_ev3q">
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="whats-next">What's next?<a href="https://docs.flathub.org/blog/introducing-app-brand-colors#whats-next" class="hash-link" aria-label="Direct link to What's next?" title="Direct link to What's next?">​</a></h2>
Today we've updated the MetaInfo quality guidelines with <a href="https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality-guidelines/#brand-colors" target="_blank" rel="noopener noreferrer">a new section on app brand colors</a>. Going forward, brand colors will be required as part of the MetaInfo quality review.
If you have an app on Flathub, check out the guidelines and update your MetaInfo with brand colors as soon as possible. This will help your app look as good as possible, and will make it eligible to be featured when the new banners ship. Let's make Flathub a more colorful, exciting place to find new apps!

We're gearing up to launch curated banners on the Flathub home page! However, before we can do that there's one more blocker: Banners need a background color for each app, and many apps don't provide this metadata yet. This is why today we're expanding our MetaInfo quality guidelines and quality checks on the website; If you haven't yet, please add these colors to your app's MetaInfo file using the `` appstream tag, and read on to learn more about brand colors.

Introducing App Brand Colors

Flathub's automatic build validation is more thorough now, and includes checks for issues we previously would have only flagged manually. There is a chance that if your app has been passing the continuous integration checks previously, it will fail now; here's why, and what to do about it.
If your application no longer passes the build validation stage in either Buildbot (for apps maintained on GitHub) or flat-manager (for direct uploads), make sure to look for specific messages in the log. Explanations for various error messages can be found in <a href="https://docs.flathub.org/docs/for-app-authors/linter">the documentation</a>. If you are interested in running the linter locally or integrating it with your own CI, please refer to <a href="https://github.com/flathub-infra/flatpak-builder-lint" target="_blank" rel="noopener noreferrer">the project page</a>.
We have also started moderating all permission changes and some critical MetaInfo changes. For example, if a build adds or removes a static permission (as seen in the <code>finish-args</code> array in the manifest) or changes the app’s user-facing name, it will be withheld for manual human review. Reviewers may reject a build and reach out for clarification about the change.
<img decoding="async" loading="lazy" alt="An example build withheld for manual review" src="https://docs.flathub.org/assets/images/moderation-52a1363ea517f514595a2ff7f662953d.png" width="2191" height="934" class="img_ev3q">
Flathub has also switched to a modern, well-maintained AppStream library, known as <code>libappstream</code>. This enables developers to use all features described in the <a href="https://www.freedesktop.org/software/appstream/docs/" target="_blank" rel="noopener noreferrer">AppStream 1.0 specification</a>, including specifying supported screen sizes for mobile devices, or video snippets to accompany static screenshots. It also improves the validation of AppStream metadata. Many thanks to <a href="https://tecnocode.co.uk/" target="_blank" rel="noopener noreferrer">Philip Withnall</a>, <a href="https://nullrequest.com/" target="_blank" rel="noopener noreferrer">Luna Dragon</a> and <a href="https://www.figuiere.net/hub/" target="_blank" rel="noopener noreferrer">Hubert Figuière</a> for their work on this across the Flatpak stack, and <a href="https://blog.tenstral.net/" target="_blank" rel="noopener noreferrer">Matthias Klumpp</a> for implementing knobs needed by Flathub in the library itself.
This work has been ongoing since 2021. At one point along the way we briefly switched over to <code>libappstream</code>, but had to revert due to unexpected breakage; however, today we are finally ready with all blocking issues addressed! While we were focused on closing the gaps to prevent potentially broken builds from being published, we regret that we failed to provide a heads-up about the coming validation changes. Any future breaking changes will be properly announced on this blog, and going forward we will also inform maintainers of affected apps about required changes in advance.

Flathub's automatic build validation is more thorough now, and includes checks for issues we previously would have only flagged manually. There is a chance that if your app has been passing the continuous integration checks previously, it will fail now; here's why, and what to do about it.

Improved build validation, increased moderation, and the long-awaited switch to libappstream

FOSDEM 2024—a free event for software developers to meet, share ideas, and collaborate—is this coming weekend in Brussels, Belgium and we'll be there! Learn where you can find us or even sit down and discuss Flathub itself, metadata and build validation, upcoming changes, and anything else on your mind.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="bof-saturday-1600-cet">BoF: Saturday 16:00 CET<a href="https://docs.flathub.org/blog/fosdem-2024#bof-saturday-1600-cet" class="hash-link" aria-label="Direct link to BoF: Saturday 16:00 CET" title="Direct link to BoF: Saturday 16:00 CET">​</a></h2>
The <a href="https://fosdem.org/2024/" target="_blank" rel="noopener noreferrer">FOSDEM website</a> describes BoFs pretty well:
<blockquote>
BOF stands for Birds Of a Feather who, as the saying goes, flock together. FOSDEM has three meeting rooms that may be booked in 30 or 60 minute blocks for discussions. All the meetings are public so anyone who is interested can attend if there is enough space.
</blockquote>
We've reserved a BoF room for Saturday, February 3 at 16:00 local time (CET, UTC+1); seating is on a first-come, first-served basis, so arrive promptly! We'll be meeting to discuss recent developments around metadata and build validation, other upcoming changes, and anything else on the minds of the attendees. Check the <a href="https://fosdem.org/2024/schedule/event/fosdem-2024-3715-flathub-flatpak-bof/" target="_blank" rel="noopener noreferrer">event</a> for the exact room details (and any scheduling changes).
We hope to see you there!
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="stands">Stands<a href="https://docs.flathub.org/blog/fosdem-2024#stands" class="hash-link" aria-label="Direct link to Stands" title="Direct link to Stands">​</a></h2>
Various Flathub and Flatpak folks can also be found around associated <a href="https://fosdem.org/2024/stands/" target="_blank" rel="noopener noreferrer">stands</a>:
<ul>
<li>Kodi: building H, level 1, stand 4</li>
<li>GNOME: building H, level 1, stand 5</li>
<li>KDE: building H, level 1, stand 6</li>
<li>Fedora Project: building AW, level 1, booth 4</li>
<li>Linux on Mobile: building AW, level 1, booth 7</li>
</ul>
Find us to chat about Flathub, app submission and maintenance, Flatpak, and the Linux desktop app ecosystem.

FOSDEM 2024—a free event for software developers to meet, share ideas, and collaborate—is this coming weekend in Brussels, Belgium and we'll be there! Learn where you can find us or even sit down and discuss Flathub itself, metadata and build validation, upcoming changes, and anything else on your mind.

Catch Us at FOSDEM 2024!

Earlier this month we shared <a href="https://docs.flathub.org/blog/quality-moderation">new app metadata guidelines</a> in response to the growth and maturity of Flathub. Today we're proud to share about that growth in a bit more detail including a huge milestone, how we calculate stats, and what we believe is driving that growth.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="milestones">Milestones<a href="https://docs.flathub.org/blog/over-one-million-active-users-and-growing#milestones" class="hash-link" aria-label="Direct link to Milestones" title="Direct link to Milestones">​</a></h2>
<img decoding="async" loading="lazy" alt="Flathub: 1.6 billion downloads; 2,400+ apps; 850+ verified apps; 1 million+ active users" src="https://docs.flathub.org/assets/images/milestones-bbf06ea4ad300901c8f39663b7bd69ce.png" width="1920" height="1080" class="img_ev3q">
To date, Flathub has served a total of 1.6 billion downloads of over 2,400 apps and their updates.
Since introducing <a href="https://docs.flathub.org/docs/for-users/verification">verified apps</a> last year, over 850 apps have been verified by their original authors; more than one third of all apps, with that number constantly increasing.
And finally, we're thrilled to announce that Flathub has surpassed one million active users. 🎉️
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="how-we-measure-growth">How We Measure Growth<a href="https://docs.flathub.org/blog/over-one-million-active-users-and-growing#how-we-measure-growth" class="hash-link" aria-label="Direct link to How We Measure Growth" title="Direct link to How We Measure Growth">​</a></h2>
We have a <a href="https://flathub.org/statistics" target="_blank" rel="noopener noreferrer">public dashboard</a> that shares some basic statistics, powered by an <a href="https://github.com/flathub-infra/flathub-stats" target="_blank" rel="noopener noreferrer">open source script</a>. We don't track individual metrics from end user machines; instead, we look at downloads of specific artifacts from the Flathub infrastructure itself. This gives us a count of installs and updates over time, downloads per country (based on the origin of requests), and some derivative data like downloads of apps in different categories.
But how can we measure how many active users we have?
Since Flathub necessarily serves downloads of Flatpak runtimes (common platforms on which apps are built), we can estimate active users fairly well. For example, when installing or updating many apps, Flatpak will automatically install the base <a href="https://freedesktop-sdk.gitlab.io/" target="_blank" rel="noopener noreferrer">FreeDesktop SDK</a> runtime on which the KDE and GNOME runtimes (and most other apps) are built. We can look at the number of downloads of updates to a recent release of this runtime to estimate how many active installs are out there getting Flatpaks from Flathub.
This methodology reveals that over the past few months there have been over a million updates of each of the latest FreeDesktop SDK runtime releases, meaning we've passed the one million active user mark.
<div class="theme-admonition theme-admonition-note admonition_xJq3 alert alert--secondary"><div class="admonitionHeading_Gvgb"><svg viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"></path></svg>note</div><div class="admonitionContent_BuS1">If anything, we believe this to be a conservative estimate as some users may be using apps that do not use the specific runtime measured.</div></div>
If you'd like to explore more of this data yourself, there's this <a href="https://klausenbusk.github.io/flathub-stats/#ref=org.freedesktop.Platform/23.08&amp;interval=infinity&amp;downloadType=updates" target="_blank" rel="noopener noreferrer">handy dashboard by Kristian Klausen</a> (<a href="https://github.com/klausenbusk/flathub-stats" target="_blank" rel="noopener noreferrer">source</a>), or you can always chat with us in <a href="https://matrix.to/#/#flathub:matrix.org" target="_blank" rel="noopener noreferrer">#flathub on Matrix</a>.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="whats-driving-growth">What's Driving Growth<a href="https://docs.flathub.org/blog/over-one-million-active-users-and-growing#whats-driving-growth" class="hash-link" aria-label="Direct link to What's Driving Growth" title="Direct link to What's Driving Growth">​</a></h2>
We attribute the growth of Flathub to a few developments over the years, and especially the last several months:
<ol>
<li>
Popular app availability: Since we started Flathub, we've seen apps like <a href="https://flathub.org/apps/org.mozilla.firefox" target="_blank" rel="noopener noreferrer">Firefox</a>, <a href="https://flathub.org/apps/com.google.Chrome" target="_blank" rel="noopener noreferrer">Google Chrome</a>, <a href="https://flathub.org/apps/com.discordapp.Discord" target="_blank" rel="noopener noreferrer">Discord</a>, <a href="https://flathub.org/apps/org.videolan.VLC" target="_blank" rel="noopener noreferrer">VLC</a>, <a href="https://flathub.org/apps/com.spotify.Client" target="_blank" rel="noopener noreferrer">Spotify</a>, <a href="https://flathub.org/apps/org.telegram.desktop" target="_blank" rel="noopener noreferrer">Telegram</a>, <a href="https://flathub.org/apps/com.microsoft.Edge" target="_blank" rel="noopener noreferrer">Microsoft Edge</a>, <a href="https://flathub.org/apps/com.valvesoftware.Steam" target="_blank" rel="noopener noreferrer">Steam</a>, <a href="https://flathub.org/apps/com.obsproject.Studio" target="_blank" rel="noopener noreferrer">OBS Studio</a>, <a href="https://flathub.org/apps/us.zoom.Zoom" target="_blank" rel="noopener noreferrer">Zoom</a>, <a href="https://flathub.org/apps/org.mozilla.Thunderbird" target="_blank" rel="noopener noreferrer">Thunderbird</a>, and many more make their way into the store. These are many of the apps people want and expect, especially if they're coming to a Linux desktop for the first time. Each time another popular app hits Flathub, it makes both Flathub and Linux that much more compelling to users.
</li>
<li>
Verified apps: We've heard that some folks have held off installing specific apps or even using Flathub altogether because they didn't want a third-party maintainer redistributing an app they rely on; <a href="https://docs.flathub.org/docs/for-users/verification">verifying apps</a> solves this by assuring users their favorite app is actually coming from its developer. With an ever-increasing number of <a href="https://flathub.org/apps/collection/verified" target="_blank" rel="noopener noreferrer">apps choosing to get verified</a>—including both big names and many newer indie apps—the trust and adoption of Flathub increases.
</li>
<li>
Steam Deck: It's not <a href="https://mastodon.blaede.family/@cassidy/111031129234702967" target="_blank" rel="noopener noreferrer">just a meme</a>; we suspect Flathub being included as the default app source for the Steam Deck's desktop mode has had a large positive effect on the usage of Flathub. Just look at some of the <a href="https://flathub.org/apps/collection/popular" target="_blank" rel="noopener noreferrer">most popular apps</a>: retro game emulators, game compatibility tools, gaming-oriented chat services, alternate game launchers—all the kinds of apps you'd expect Steam Deck users to want. And in fact, "game" is the single most common category of app on Flathub. It turns out selling <a href="https://www.theverge.com/2023/11/9/23954205/valve-steam-deck-multiple-millions" target="_blank" rel="noopener noreferrer">"multiple millions" of devices</a> has an impact on the ecosystem!
</li>
<li>
Linux distro adoption: In addition to shipping on Steam Deck, Flathub now comes included out of the box on at least Clear Linux, Endless OS, KDE Neon, Linux Mint, Pop!_OS, and Zorin OS—and <a href="https://pagure.io/fesco/issue/2939" target="_blank" rel="noopener noreferrer">as of Fedora 38</a>, Flathub is available in its entirety when enabling third-party software sources. Flathub is the preferred app store for Linux, and its grassroots adoption across the Linux desktop ecosystem proves that.
</li>
<li>
New apps: Last but definitely not least, we've entered a thrilling chapter of Flathub as an ecosystem. It's not just another source to get popular, big-name apps you'd expect to be able to get anywhere else; Flathub has become the preferred app store for a growing number of indie, open source developers. Developers are increasingly submitting their own new apps and directing their users to Flathub; from <a href="https://circle.gnome.org/#apps" target="_blank" rel="noopener noreferrer">all 50+ GNOME Circle apps</a> to apps like <a href="https://flathub.org/apps/org.endlessos.Key" target="_blank" rel="noopener noreferrer">Endless Key</a>, <a href="https://flathub.org/apps/com.librumreader.librum" target="_blank" rel="noopener noreferrer">Librum</a>, <a href="https://flathub.org/apps/io.github.NickKarpowicz.LightwaveExplorer" target="_blank" rel="noopener noreferrer">Lightwave Explorer</a>, <a href="https://flathub.org/apps/net.sapples.LiveCaptions" target="_blank" rel="noopener noreferrer">Live Captions</a>, and <a href="https://flathub.org/apps/io.github.alainm23.planify" target="_blank" rel="noopener noreferrer">Planify</a>, Flathub is the best way to get apps into the hands of Linux users.
</li>
</ol>
And of course a large part of Flathub's continued growth has been due to the incredible work of the Flathub admins, contributors, and volunteers who have helped ensure Flathub remains the trustworthy and reliable service it has always been known as.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="heres-to-whats-next">Here's to What's Next!<a href="https://docs.flathub.org/blog/over-one-million-active-users-and-growing#heres-to-whats-next" class="hash-link" aria-label="Direct link to Here's to What's Next!" title="Direct link to Here's to What's Next!">​</a></h2>
It's easy to pat ourselves on the back for these milestones (and it's well deserved!), but equally important is to look forward. Over the coming months we're excited to continue tackling <a href="https://discourse.flathub.org/t/flathub-in-2023/3808#whats-next-8" target="_blank" rel="noopener noreferrer">the roadmap we laid out last year</a>, including continued work towards payments and the new organizational structure for Flathub.
We're also increasing our engagement with third-party developers and ISVs to share why they should bring their apps to the million-plus Flathub users on Linux, continuing to improve documentation, and working towards <a href="https://docs.flathub.org/blog/quality-moderation#curation">curation and improved presentation of apps</a>. There's a lot more coming and always more to do; if you want to get involved, chat with us in <a href="https://matrix.to/#/#flathub:matrix.org" target="_blank" rel="noopener noreferrer">#flathub on Matrix</a>.
Thank you for reading, and happy downloading!

Earlier this month we shared new app metadata guidelines in response to the growth and maturity of Flathub. Today we're proud to share about that growth in a bit more detail including a huge milestone, how we calculate stats, and what we believe is driving that growth.

Over One Million Active Users, and Growing

Flathub has grown massively over the past few years, making it easier than ever to get a ton of apps all from one place—but with that growth comes new problems. We're here with a solution to ensure developers' apps, Flathub, and the entire Linux desktop ecosystem is presented in what we believe is the best light possible.
Today, Flathub has over 2,400 apps, including many of the big names you would expect. In the early days our goal was mostly to make it easy to get the latest version of popular apps via Flatpak, and we can safely say this has been achieved: not only can you get pretty much any app on Flathub, they are often directly maintained by the developer—and it's the primary channel many new app developers choose for shipping their apps.
<img decoding="async" loading="lazy" alt="App cards with high quality metadata on the homepage" src="https://docs.flathub.org/assets/images/good-metadata-apps-b769542fb67d47350800d81536cf4b92.png" width="1161" height="651" class="img_ev3q">
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="more-apps-more-problems">More Apps, More Problems<a href="https://docs.flathub.org/blog/quality-moderation#more-apps-more-problems" class="hash-link" aria-label="Direct link to More Apps, More Problems" title="Direct link to More Apps, More Problems">​</a></h2>
However, having lots of apps comes with some new (in this case nice to have) problems. While there are a lot of beautiful modern apps, there are also a lot of apps with low quality metadata, ugly icons, or out of date screenshots. This means that looking at the new and updated lists on the Flathub home page you get the impression that most of the apps on Flathub are low quality.
One of the biggest reasons for the prevalence of low quality app metadata is probably that historically people were not discovering new apps from their repositories very often. Instead, they were mostly installing the same few classics with well-known brands (VLC, Blender, etc.), or relying on word of mouth for discovery. Now that new apps are being released on a weekly basis, app metadata becomes much more important for introducing people to these new apps.
The unfortunate result of the status quo in metadata quality is that many apps don't look inviting for new users, and it's difficult to find truly high quality apps among the rest.
So how can we make Flathub a place for people to discover awesome apps? We've thought about this quite a bit, and landed on a two-pronged approach:
<ol>
<li>Raise the bar for metadata for all apps</li>
<li>Introduce curation to highlight the best apps</li>
</ol>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="raising-the-bar">Raising the Bar<a href="https://docs.flathub.org/blog/quality-moderation#raising-the-bar" class="hash-link" aria-label="Direct link to Raising the Bar" title="Direct link to Raising the Bar">​</a></h2>
As a first step towards improving metadata quality across the board we have added new, detailed <a href="https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality-guidelines">documentation for app metadata</a>. This new page goes over all the most important aspects, and which common mistakes to avoid. These include, for example:
<ul>
<li>App icons that fill the entire canvas</li>
<li>Summaries repeating the app name</li>
<li>Screenshots with no window shadow</li>
</ul>
We're also introducing a new review system for app metadata, where editors rate which of the criteria a specific app meets. As an app developer you can see the state of your metadata on the app page on Flathub.
<img decoding="async" loading="lazy" alt="Developer-facing UI exposing the metadata ratings" src="https://docs.flathub.org/assets/images/moderation-developer-view-7a055ad665ac915223c4a935377accbe.png" width="1311" height="914" class="img_ev3q">
<img decoding="async" loading="lazy" alt="Developer-facing UI exposing the metadata ratings" src="https://docs.flathub.org/assets/images/moderation-developer-sidebar-32b01331283e3dd5340182808e7d84ae.png" width="1311" height="914" class="img_ev3q">
If editors flagged issues with your app you can address them in the next release. Once the new release is on Flathub you can request a re-review. The status of your app will be updated accordingly.
If you are not an icon designer, getting your icon to meet the guidelines can be challenging. Luckily there are designers from the community you can ask for help! The <a href="https://matrix.to/#/#appicondesign:gnome.org" target="_blank" rel="noopener noreferrer">GNOME App Icon Design</a> and <a href="https://matrix.to/#/#visualdesigngroup:kde.org" target="_blank" rel="noopener noreferrer">KDE Visual Design Group</a> Matrix rooms are good examples of places to ask.
This does not affect the app review process for apps being published on Flathub. We will continue to accept apps that don't fully meet the new quality guidelines. However, we do want to highlight apps that meet the guidelines, and try to show them in more prominent places on the website.
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="curation">Curation<a href="https://docs.flathub.org/blog/quality-moderation#curation" class="hash-link" aria-label="Direct link to Curation" title="Direct link to Curation">​</a></h2>
Our hope is that with better documentation and developer outreach we can get to a solid set of apps with high quality metadata: Short descriptions, good icons, correctly sized screenshots with good content, and so on. Once we have that, we have a lot of new possibilities with regard to curation. For example, we've been exploring having app banners with app icons and screenshots on the home page. Other ideas we'd like to experiment with in the future include curated lists of apps, seasonal/topical recommendations, and editorial blog posts.
<img decoding="async" loading="lazy" alt="Flathub home page mockup with app banners including screenshots" src="https://docs.flathub.org/assets/images/homepage-banners-34edbc748fcb7b45eeea652ab91738de.png" width="1570" height="1550" class="img_ev3q">
Our current plan is to start off with some simple banners on the homepage and iterate from there. The moderation backend for this already exists, and we're planning on rolling out the frontend soon.
At this stage our focus is on the Flathub website, but of course eventually we want to make this data available to native app store clients as well.
This effort will also help to improve the Flathub-wide search and the discoverability and attractiveness of apps on Flathub from the rest of the internet.
<img decoding="async" loading="lazy" alt="Mockup of GNOME Software with banners including screenshots" src="https://docs.flathub.org/assets/images/banner-native-a2cc63060b48faa603a78f3fc18edb6a.png" width="1168" height="1044" class="img_ev3q">
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="whats-next">What's Next?<a href="https://docs.flathub.org/blog/quality-moderation#whats-next" class="hash-link" aria-label="Direct link to What's Next?" title="Direct link to What's Next?">​</a></h2>
As of today, if you have an app on Flathub you can log in on the website, and see the app metadata ratings for your apps. Please have a look at your apps' ratings and the new documentation and make sure your app's metadata is in shape when we start rolling out banners over the coming weeks :)
If you run into issues or have questions please contact us in <a href="https://matrix.to/#/#flathub:matrix.org" target="_blank" rel="noopener noreferrer">#flathub on Matrix</a>.
It's early days for all of this, but we're excited to continue working in this direction. Watch this space!

Flathub has grown massively over the past few years, making it easier than ever to get a ton of apps all from one place—but with that growth comes new problems. We're here with a solution to ensure developers' apps, Flathub, and the entire Linux desktop ecosystem is presented in what we believe is the best light possible.

Raising the Bar: Introducing the new App Metadata Guidelines

You can now find our new documentation at <a href="https://docs.flathub.org/">docs.flathub.org</a> or well here, if you're reading this.
Please read through it and send us feedback if you find anything missing or unclear. You can also send us a <a href="https://github.com/flathub/documentation" target="_blank" rel="noopener noreferrer">pull request</a> if you want to help us improve it.

You can now find our new documentation at docs.flathub.org or well here, if you're reading this.