About
About APKBrowse
APKBrowse is a catalogue of Android apps built around one idea: you should be able to check a file rather than trust a page. Every build we hold publishes the fingerprint of its bytes and the certificate that signed it, and where an official store carries the app, we send you there first.
This is a demonstration catalogue. Every app listed here is fictional. They exist to show how a provenance-first registry would work — the publishers, the version histories and the builds are invented, and nothing on this site should be downloaded expecting real software. The reasoning, the checks and the guidance are not fictional, and apply to any APK from any source.
The problem this is about
On Android, an app's identity is its package name — the string that decides which private data directory it opens and which permissions it inherits. Anyone can put any package name on any file. That is the whole difficulty in one sentence. A file claiming to be a well-known app is trivial to produce; a file that can prove it came from that app's author is not.
Most sites that host APKs answer this with reassurance. They tell you a file is safe, clean, or scanned, and the words do a lot of work that the underlying checks do not. The trouble is that safety is not a property a file has — it is a claim about what code will do when it runs, and that is a hard question that a download page is in no position to answer.
Provenance is a different question, and a tractable one. Where did this build come from? Did it change on the way to you? Was it signed by the same author as the last release? Those have real answers, they can be checked mechanically, and they can be checked again by you, independently, without taking our word for any of it. That is what this catalogue records.
How a listing is verified
The official store link comes first
Where an app exists on an official store, that link sits above the download on the listing. A store binds an app to an accountable developer account, updates it automatically, and can remove it from every device if it turns out to be harmful. A direct APK does none of those things. When the store build does what you need, it is simply the better option.
Every build's SHA-256 is published
For each version we hold, the listing shows the SHA-256 of the exact file. Compute it yourself after downloading and compare: a match means you have the file we hold, byte for byte, and nothing altered it in transit. A mismatch means you do not, and the file should be deleted rather than investigated.
Signing certificates are recorded and compared
We record the SHA-256 fingerprint of the certificate that signed each build and compare every new submission against earlier releases of the same package. A mismatch blocks approval. This is what catches repackaging — the most common way a familiar-looking APK turns hostile — because an attacker cannot sign with a key they do not have.
Beyond the automated checks, a person reads every submission before it is listed. The review asks whether a submission is what it claims to be — not whether the app is any good. The review queue is visible rather than hidden, because a moderation process nobody can see is indistinguishable from no moderation process.
What we do not do
We do not scan for malware.No antivirus engine runs here, and no listing has been through one. When a listing says a signature was verified, the claim is exact and narrow: the certificate on this build matches the certificate on the previous release of the same package. That catches repackaging. It says nothing about what the code does, and we would rather repeat that on every page than let "verified" quietly inflate into a promise we are not making.
We do not list pirated, cracked or modified buildsof other people's software, whoever submits them. This is partly a legal position and mostly a practical one: those files are where the overwhelming majority of Android malware lives, and a catalogue built on provenance cannot host builds whose entire premise is that the author did not authorise them.
We do not fill requests. Going and finding a file because somebody asked for it by name is the exact failure this site is arguing against — it produces listings whose only provenance is that we found them. The request page explains what to do instead.
What we expect of you
Publishing a hash only matters if somebody checks it, and the checks are yours to make. After downloading, compute the SHA-256 and compare it with the listing. Before installing an APK for an app you already have, print its signing certificate and compare the fingerprint with the copy on your device. Both take under a minute, and between them they catch the two things a store would otherwise have caught for you.
And take the store link seriously when it is there. It sits above the download button on purpose. For most apps, on most days, sideloading is strictly worse: you take on the update burden, you lose the remote removal path, and you get the same app more slowly through a channel you have to verify by hand. The blog works through each of these in detail, and the safety guide is the short version.