[Question] Backend engineers, I have a question

Joker King

Registered Member
Joined
Aug 11, 2018
Messages
51
Reaction score
85
Hi BHW Family,

I've been trying to understand how large Android app repositories work and there's one thing I can't figure out. I'm talking about sites like APKPure, APKMirror, Uptodown, Aptoide and similar platforms. I know detecting a new app version isn't the hard part. You can monitor package names, version codes, metadata, changelogs, screenshots and all that. But what I don't understand is how the APK itself is obtained automatically.

For example, a developer releases a new version on Google Play, the update gets detected within minutes, and shortly after the APK is already available on websites like APKPure or APKMirror. Since Google Play doesn't provide a public API to download APK files, where does the APK actually come from?

Do these platforms mainly rely on developer submissions, user uploads, device farms, multiple authorised sources, or some other backend ingestion pipeline? I'm looking for code or ways to bypass Google's systems. I'm just trying to understand the backend architecture and how platforms handling millions of apps automate this process at scale.

If anyone has experience with large app repositories or knows how this generally works, I'd really appreciate your insights. Thanks!
 
Hi BHW Family,

I've been trying to understand how large Android app repositories work and there's one thing I can't figure out. I'm talking about sites like APKPure, APKMirror, Uptodown, Aptoide and similar platforms. I know detecting a new app version isn't the hard part. You can monitor package names, version codes, metadata, changelogs, screenshots and all that. But what I don't understand is how the APK itself is obtained automatically.

For example, a developer releases a new version on Google Play, the update gets detected within minutes, and shortly after the APK is already available on websites like APKPure or APKMirror. Since Google Play doesn't provide a public API to download APK files, where does the APK actually come from?

Do these platforms mainly rely on developer submissions, user uploads, device farms, multiple authorised sources, or some other backend ingestion pipeline? I'm looking for code or ways to bypass Google's systems. I'm just trying to understand the backend architecture and how platforms handling millions of apps automate this process at scale.

If anyone has experience with large app repositories or knows how this generally works, I'd really appreciate your insights. Thanks!
Please explain
 
Alright, I've developed and deployed something similar before and I'll respond based on how that particular client handled it - this may or may not be how apkpure or apkmirror handle it.

First, is very obviously a human layer. These are people who submit or volunteer submission of apps. In most cases, they are given an uploader that detects their system architecture, display resolution and language - then monitors their local play store for updates on particular apps. Their job is to just click download. The submission app automatically detects the files (based APK and splits) and uploads it to the APK Provider's servers.

Obviously this requires extended permission, so most volunteers use a spare device to do this. They often get paid a base amount for keeping the device switched on and connected to the internet. And approving play store downloads when the app notifies them.

This is the high quality stuff, because it gives the site owners access to a variety devices, regional variants, arch structures and DPIs.

Second, is a distributed network of cloud phones and emulators with playstore logged in.

This is similar to the above, but the download management app installed here is more autonomous and other automation is enqueued to take care of things.

//

The next layer is the "installer" - which is a custom universal APK provided by sites like APK mirror and APK pure.

The point of this installer is to download the bundle from these mirrors, then based on the user's device extract the split specifics and run the local install. In most cases, Android's default installer cannot install these bundles.

So APKPure uses XAPK, while APKMirror uses APKM, then there's APKS with SAI (Split APK installer)

These are just zip extractors that package data and stream the necessary split files (and sometimes include OBB data) in one file, based on your device and location.

//

Some installs still have a universal APK - especially for very basic apps or ones with solo devs or newer/inexperienced developers.

So for example, this app has just one universal APK -

https://www.apkmirror.com/apk/weee-...ry/weee-asian-grocery-delivery-26-10-release/

But for example this Capcut download has 34 splits

https://www.apkmirror.com/apk/byted...r-18-4-0-3-android-apk-download/#safeDownload

1 x Base APK
2 x Architecture Specific Split
7 x DPI specific split
25 x Language specific split
2 x Dynamic Feature Split

All of this are provided as one APKM file that the APKmirror extracts and streams to your system based on your device and locale.

//

Hope this was helpful
 
One thing people forget is staged rollouts. When Play says “new version” it doesn’t mean every account/device can pull it right away, so these sites usually have a big matrix of regions, accounts, device profiles etc and they just catch whichever one gets it first. Then everything is verified by package name + versionCode + signing cert hash before it goes public, otherwise user uploads would be a nightmare.

Also dev submissions are more common than people think, especially for smaller apps wanting distribution outside Play. For big apps it’s more like ingestion queues, scanners, dedupe, split handling, CDN push... not some guy manually uploading 500 apks a day. The fast ones are basically running monitoring + authorised installs at scale, not relying on a public Google download API.
 
Back
Top