The Paperwork Nobody Tells You About: Submitting to F-Droid

Everything F-Droid needs from Photo Sweep was already sitting in the repository before I opened a single form: fastlane metadata, an icon, two screenshots, a license that qualifies. The part that took actual thought wasn't producing any of that. It was figuring out what the submission process even is — because it isn't a build system you configure. It's a GitLab issue.

One issue, four boxes, a pasted template — that's the entire submission surface.

What "ready to submit" actually meant

By the time I went looking for the submission form, the prerequisites were already done, mostly as a side effect of building the app properly rather than because I'd read F-Droid's rules in advance:

• android/fastlane/metadata/android/en-US/ had the title, both descriptions, and changelogs for versionCode 10000 and 10001 already checked in.
• The license is AGPL-3.0, there's no Google Play Services, no Firebase, no analytics — and a permission set that CI actively fails the build over if it grows.
• A 512×512 icon rendered from the adaptive icon the app ships, and two phone screenshots.

The one gap I noted for later rather than blocking on: a screenshot of the deck mid-swipe. The two I had cover the month list and the settings screen. Neither shows what the app actually is. The listing works without it — it would just convert better with it.

The form itself

The request lives at gitlab.com/fdroid/rfp/-/work_items/new. Set the type to Issue, title it with the app name, and there are four checkboxes on the template:

• Complies with the inclusion criteria — trivially checkable if you've read the policy page once.
• Not already listed in the repo or issue tracker.
• Original author notified and does not oppose inclusion — true by construction when you're the author submitting your own app.
• Donated to support F-Droid's maintenance — optional, and left unchecked honestly rather than performatively ticked.

Below the checkboxes, the template wants a source link, a note on whether the app exists in another store (none — Photo Sweep isn't on Google Play and there's no plan to change that), the license identifier, a category, a short summary line, and a longer description that F-Droid will show verbatim on the app's listing page.

One detail worth calling out explicitly, because it's the kind of thing that's easy to get wrong under a deadline that doesn't actually exist: submit against the tag, not the branch. I pointed the issue at android-v1.0.1 specifically — not 1.0.0, which shipped with a sign-in bug that fails on a single dropped connection. More on that tag in a separate post; the point here is that the inclusion request is permanent public record of which commit you're vouching for, so it's worth getting the pointer right the first time.

The wait, and the rate limit

If the form throws "this endpoint has been requested too many times," that's GitLab rate-limiting anonymous traffic, not a rejection. Wait a minute, submit again.

After that, the honest expectation is weeks to months. F-Droid is volunteer-run, and there's no lever to pull to speed it up. I found that clarifying rather than frustrating: it meant I stopped treating F-Droid inclusion as step one of the launch and started treating it as a background process that runs independently of everything else — submit it, then don't let anything downstream wait on it.

Why this is worth writing down

None of this is hard. It's just undocumented in the sense that matters: you won't find "here's what the request literally looks like" anywhere until you're already filling it in. The actual bar is a checklist and a paste of metadata you should have anyway for a well-behaved app. The friction is entirely in not knowing that in advance.

Series: Launching Photo Sweep.