Accrescent, F-Droid, and where degoogled phones should get their apps
Accrescent, F-Droid, and where degoogled phones should get their apps
A degoogled phone solves the tracking problem and immediately creates a new one: where do you get apps? There's no Play Store, and sideloading APKs from random websites is how people end up with malware on otherwise clean devices. The two serious answers are F-Droid and Accrescent. They make different trade-offs, and picking between them without understanding those trade-offs is how you end up with a phone that feels private but isn't.
What F-Droid actually does
F-Droid is the old guard, and its core promise is unusual: it rebuilds apps from published source code on its own infrastructure, so the APK you download doesn't have to be taken on faith from the developer. The F-Droid verification process compares the rebuilt binary against the developer's build and, where they match byte-for-byte minus the signing block, distributes the developer-signed result. A growing minority of apps pass this reproducible-builds check — something the Play Store has never offered anyone.
Here's the part that gets underplayed. For most apps in the catalogue, the build doesn't reproduce, and F-Droid signs the binary with its own keys instead of the developer's. Community analysis puts apps without reproducible builds at roughly nine in ten of the main repository — meaning the typical F-Droid install is signed by F-Droid, not by the person who wrote the app. Whether that's a problem depends entirely on how much you trust F-Droid's build infrastructure, which is a perfectly reasonable position to hold but should be a deliberate one.
Two other real drawbacks. First, updates lag upstream by days or sometimes a week because the build queue is manual and deliberate. For a messaging app that matters — a security patch that takes ten days to reach you is a real window. Second, F-Droid does not audit app behaviour. The WireGuard incident is the clean illustration: the app shipped for months with a self-updater that broke F-Droid's own rules, and nobody at F-Droid noticed until the developer raised it. Building from source limits what a malicious developer can hide; it doesn't eliminate it, and it clearly didn't catch an open, documented rule violation either.
What Accrescent does differently
Accrescent takes the opposite bet. Developers upload their own signed APKs; the store never rebuilds or re-signs anything. The binary you install is exactly the developer's, and the store's security model is built around guaranteeing that: app signing key pinning means a hash of each developer's signing key is baked into signed repository metadata, so even if Accrescent's servers were compromised, they couldn't serve a malicious update without the developer's actual key. Metadata is signed, downgrade-protected, and carries a minimum version floor. On Android 12 and up, updates run unattended and unprivileged.
The cost is honesty about scope. Accrescent does not build from source, so if a developer ships a backdoor in their own binary, Accrescent will happily install it. Its maintainers are explicit about this: the store protects you from a compromised store and from third-party tampering, not from a malicious developer. And the catalogue is much smaller than F-Droid's — that's not a bug you can file, it's just where the project is.
So the failure modes are genuinely different, not ranked. F-Droid's rebuild model guards against a developer whose public source is clean but whose released binary isn't, at the cost of trusting F-Droid's infrastructure and signing keys. Accrescent's model guards against tampering anywhere between the developer and your phone, at the cost of trusting every developer directly. Pick according to which worries you more — or run both, which is what most careful users end up doing.
The GrapheneOS community has been vocal about preferring the developer-signed model, arguing that on a hardened phone the threat you actually care about is a tampered binary. Their forum discussion of the two stores is worth reading in full if you want the argument at its sharpest, including the observation that a week-old security patch is itself a vulnerability. I think they're right about the direction of travel and unfair about the rest — reproducible builds are a genuinely good idea that most of the industry hasn't attempted at all.
The wider Australian picture
There's a local wrinkle worth naming: government services. myGov, Service NSW and most state apps are built against Google Play Services, and on a fully degoogled device they either don't run or run badly. If you rely on those apps, a sandboxed Play Services setup (GrapheneOS supports this cleanly) is part of the answer, and it changes the app-store calculus too — once you're running sandboxed Play for one or two government apps anyway, the purity question of "no proprietary stores" is already settled and the practical question becomes which store you use for everything else. My rule: F-Droid for the small, developer-run apps where the rebuild model adds value; Accrescent for anything that gets security updates on a clock; Play (sandboxed) only for what cannot exist elsewhere.
The other AU-specific note is privacy regulation context rather than app stores. With the Privacy Act reforms grinding through and the OAIC active on tracking-technology enforcement, the tracking surface a degoogled phone removes is the same surface regulators have been taking an interest in. Nothing in this piece is legal advice, but the direction of both the market and the law is the same: less silent data collection by default. A phone where every app install passes through a verifiable channel is a small, concrete piece of that.
What this means on our builds
Both stores are one tap away on every degoogled phone we ship. GrapheneOS builds come with Accrescent pre-installed — which is GrapheneOS's own recommendation, since installing it from the OS vendor's app store chains verification back to the hardware root of trust. Our LineageOS and CalyxOS units ship with F-Droid, specifically the Droid-ify client, which is a nicer front-end than the stock app. Nothing stops you adding the other, and on LineageOS I'd suggest you do.
Three practical notes for Australian users:
- Banking apps: install from the store, not an APK mirror. Several AU banks flag sideloaded installs and some quietly refuse to run at all. Store-installed apps with verifiable signatures generate fewer support headaches — and if your bank isn't on either store, a work profile with a sandboxed Play Store is a better answer than an APK from a mirror site.
- Skip third-party repos like IzzyOnDroid unless you specifically know why you're adding them. Each repo added is another party whose infrastructure you're trusting. IzzyOnDroid distributes developer builds directly, which changes the trust model from the main F-Droid repo — but "different" is not "worse" or "better", it just needs to be a decision you actually made.
- Hash-check anything from GitHub Releases. Projects like Signal publish official APKs there, and matching the published SHA-256 against the file takes ten seconds with AppVerifier. This covers the gap both stores leave: apps that aren't in any catalogue.
One last thing worth saying plainly: no app store fixes an unpatched OS. Whatever you use to install apps, the updates that matter most arrive through the system updater, and that's the pipeline to verify first. If you're choosing between OS builds rather than app stores, our GrapheneOS vs LineageOS comparison covers that decision directly.