One Analysis Finds 72.5% of F-Droid's Latest Apps Look AI-Written

An independent review of F-Droid's Sept. 12 batch of app updates found that 74 of 102 apps, or 72.5%, show what its author calls clear signs of being largely written by a large language model, according to a post by a blogger using the handle tintotint, published Sept. 15 on their personal site.

The count rests on one person's judgment, not a detector. Tintotint's post is explicit about that: "there's no way to effectively detect slop, so I propose a rough 3 tier system," sorting each app into "Mostly AI," "Hard to say," or "No signs of AI" by reading recent commits, issue trackers, and how a project describes itself. On that scale, 9 apps (8.8%) landed in the middle tier and 19 (18.6%) showed no signs at all, among them Nextcloud, Wikipedia's official client, and the strategy game Unciv, all three flagged as looking human-written.

How the count breaks down

Category	Apps	Share
Mostly AI-written	74	72.5%
Hard to classify	9	8.8%
No signs of AI	19	18.6%

One developer, using the handle brandonp2412, maintains multiple apps in the sample under different package namespaces, all of which tintotint flagged as AI-generated, a pattern the post says raises questions about whether an autonomous agent rather than a person is pushing some of the commits.

The Codeberg problem

Four of the five apps in tintotint's sample that are hosted on Codeberg show clear signs of AI generation. That puts them on the wrong side of a rule Codeberg's own membership adopted two months earlier: a new Section 2.7 in its Terms of Use bars "projects that mostly consist of code written by 'generative AI'-tools," naming Claude and OpenAI Codex specifically, according to coverage of the vote by It's FOSS. Codeberg e.V. members passed the measure 358 to 144, with 14 abstentions, in a vote that closed July 22. Enforcement is complaint-driven rather than a proactive scan, and It's FOSS reported Codeberg does not plan to purge existing repositories on its own.

F-Droid itself has no such rule

F-Droid's own inclusion policy says only that "the application should be actively maintained when it's included and the author should commit to provide ongoing maintenance," and that maintainers verify license compliance, source availability and buildability. Nothing in that policy addresses how the code was written.

A thread on the F-Droid community forum has been debating that gap since August, weeks before tintotint's post existed. Contributor Licaon_Kter, an active F-Droid maintainer, has said the project's mandate stops at confirming published source code carries a libre license, not at judging how it was produced, and points questions about auto-translation or summary features toward the browser projects that ship them rather than toward F-Droid itself. A participant posting as strypey has pushed back on that framing, asking whether an app quietly downloads a proprietary model file or calls a paid remote service at runtime, arguing the licensing check alone cannot see either. Another, hackermen4567, has proposed that F-Droid verify the licensing and reproducibility of any bundled model the way it already verifies app source, and tag the result as an anti-feature without passing judgment on it. A third participant, posting as Zolidor, has tried to split the underlying question into three separate cases: apps that bundle a local model file, apps written with AI assistance but reviewed line by line, and apps that are thin wrappers around a remote AI service, each of which the current policy treats identically. As of mid-September, F-Droid has adopted none of the proposals.

The case against reading too much into the number

Tintotint's own post concedes the limits: no code-quality review, no automated cross-check, and a sample of 102 apps out of the thousands F-Droid carries. A developer using an AI assistant for boilerplate and reviewing every line would look identical, on this method, to one who is not reading the code at all, since both leave the same kind of commit history and the same generic variable names behind. The post's own three-tier language, "Hard to say" sitting between two more confident tiers, is an admission that close to a tenth of the sample resisted a clean call even by the author's own rule, and the 72.5% headline number depends on treating that tier as excluded rather than folded into either side.

What would change this picture

The finding would look different if it came from an automated detector run across F-Droid's full catalog rather than one week's batch, or if a maintainer named in the post disputed the classification of their own app, the way an accused developer on GitHub or Codeberg sometimes does when a similar claim goes around. Neither has happened yet. What has already happened is the timing: F-Droid's forum was already asking whether it needs a policy like Codeberg's before this specific number existed, which means the debate does not depend on any single blogger's tier system to keep going. The next concrete step is whichever comes first, an F-Droid maintainer response to tintotint's post or a formal proposal out of the forum thread that has been running since August, the kind of open-source trust question this site has also tracked in OpenClaw's uneven security record after its growth to 388,000 stars and in VoiceStudio's licensing gap on GitHub's trending page.