How to deploy a private Android app store without Google Play

Your warehouse scanner app is never going on the public Play Store. It runs on 300 handhelds, it carries your stock logic, and a public listing would be absurd. An internal enterprise app store is how you get that build onto the devices, keep it current, and know exactly who runs which version. Here's how to set one up on Android in 2026, without publishing anything publicly.

Who this guide is for, and the three routes you can take

This is written for the person who owns the Android fleet in a company of 50 to 5,000 devices: one IT admin, maybe two, no dedicated mobility team. You have at least one app built in house or by an agency, and someone in operations is still emailing an APK file around. That habit is what we're replacing.

Three routes exist for private app distribution on Android, and they're not interchangeable. The first is publishing your app as a private app inside Managed Google Play. Google hosts and serves the binary, your organisation is the only audience, and nothing appears in public search. The second is uploading the APK to your management platform, which then installs it directly on the device. No Google hosting involved, which is the only option for rugged hardware sold without Google Mobile Services. The third is a self-service catalogue on the device, an enterprise app store where employees pick what they need from a list you curate, with required apps installed silently behind the scenes.

Most fleets end up using two of the three at once. Here's how they compare.

One thing the table can't show: none of these routes asks the user to enable installs from unknown sources. That prompt belongs to sideloading, and on a device enrolled in Android Enterprise it never appears. If your current process involves explaining a security toggle over the phone, you're not doing managed distribution yet.

What you need before you start

Four prerequisites, in order of how often they block a project.

• An Android Enterprise binding. Your management platform has to be bound to an Android Enterprise organisation, which is what gives you Managed Google Play and the managed account model. Setup takes minutes and needs a Google account that isn't someone's personal one. Use a shared IT mailbox.
• A decided enrollment mode. Fully managed (company-owned, IT controls the whole device), work profile for employee-owned phones, or dedicated device for single-purpose kit like a scanner or a ticket terminal. The mode decides what silent install can do: on a fully managed or dedicated device your platform can install an uploaded APK directly, while inside a work profile an internal build normally travels as a private app through Managed Google Play.
• A signed release build. Android identifies an app by its package name plus its signing certificate, and that pair can never change. Lose the keystore and you can't update the app, only uninstall and reinstall, which drops local data. Store it with your production secrets, not on the build machine of the contractor who left in March.
• A Play developer account, sometimes. When you publish your first private app from an EMM console, Managed Google Play creates a Play developer account for your organisation with no registration fee. You only pay the one-off 25 USD registration if you want your own full Play Console account, which you do need if you insist on holding your own app signing key for bundles.

Deploying your internal enterprise app store step by step

1. Prepare the APK

Build a release variant, signed with your production key, and bump the versionCode integer. Android refuses to install a lower versionCode over a higher one, so a rollback means uninstall and reinstall. Decide your version numbering before the first deployment, not after a bad build reaches 400 devices. The format itself hasn't changed: an APK is still the file you hand to a management platform, even though new apps on the public Play Store have had to be app bundles since August 2021. That rule governs publishing, not installing.

Two checks worth running before you ship anything. Open the manifest and read the permission list out loud; anything you can't justify to a works council will come back at you later. Then confirm your target API level, because Play rejects uploads that lag too far behind the current requirement.

2. Publish the private app, or upload the build

For the Managed Google Play route, you do this from inside your management console, not from the Play Console. Google's own documentation is blunt about how little it takes: you provide a title and the app file, and most apps are ready for distribution within 10 minutes. Two limits to plan around. You can upload 15 private apps per day, web apps included in that count. And a private app published this way can never be converted into a public one, nor transferred to another developer account.

If you publish dozens of builds a year, the Custom App Publishing API is the better path: apps are permanently private and can appear in the managed store in as little as five minutes, against more than two hours through the Play Console. Check whether your platform exposes it before you write scripts against it yourself.

For the direct route, upload the signed APK to your platform, give it a display name and an icon, and it becomes a catalogue entry. This is also the fallback when Managed Google Play is out of reach, which happens more often than vendors admit: Managed Google Play needs Google Mobile Services, so rugged handhelds shipped without GMS can't use it at all.

3. Target the right groups

Never assign an app to the whole fleet on day one. Build groups that match how people actually work (warehouse, field technicians, store managers, head office) and pilot on one group of ten devices for a week. Then decide, per group, whether the app is required or optional. Required apps install silently before anyone opens the catalogue. Optional apps sit in the store and wait, which is the right setting for a tool only part of a team needs.

Group design is boring and it's the thing that saves you later. A clean group structure is what lets you hold version 4.2 on the night shift while the day shift gets 4.3.

4. Push the managed configuration

This is the step most teams skip, then regret. App configuration sends settings to the app from the server before anyone opens it: backend URL, tenant ID, SSO options, feature switches. On Android these are managed configurations declared in the app's own XML and read through the RestrictionsManager API. The limit is hard: an app accepts only what its developer declared. If your internal app has no configuration schema, adding a handful of keys is usually an afternoon of work, and it removes the first-launch screen where a driver is asked for a server hostname he has never seen.

Keep the values in the console, never baked into the APK. Rebuilding an app because a URL moved is wasted time.

5. Handle updates and versions

Decide who controls update timing. Auto-update everywhere is fine for an app with a stable backend and hostile for an app tied to an ERP release. Most fleets we see settle on staged updates: pilot group first, then everyone, with a documented rollback plan that acknowledges the uninstall and data loss problem.

One trap specific to Managed Google Play: a new version that requests new permissions can block the update until an admin accepts them again in the console. Nobody notices for three weeks, then someone asks why half the fleet is still on the old build. Put a monthly version check in your routine.

Security and compliance

Signing is your integrity control, and the only one that really matters. The package name plus certificate pair is what Android uses to decide whether an update is genuinely yours. Treat the keystore like a production credential with restricted access and an inventory of who holds it.

Apps served through Managed Google Play are scanned by Play Protect, private listings included, which is a real argument for that route over direct APK upload when the hardware allows it. On Android 13 and later, apps installed outside a store also lose the ability to obtain Accessibility permissions, which breaks some legacy automation tools and tends to surface during a pilot rather than before.

Then there's the change everyone in this area is watching. Google now requires developer verification for apps installed on certified Android devices outside Play, with enforcement starting 30 September 2026 in Brazil, Indonesia, Singapore and Thailand and a global expansion announced for 2027. Good news for fleets: apps distributed through your organisation's store on managed devices are exempt, because the IT admin has already vetted them. Bad news for anyone still shipping APKs by download link to unmanaged phones. That practice has a visible expiry date now.

On GDPR, keep two things separate. An internal app store handles which binaries land on which device, so your records of processing should describe the device inventory and app assignment data your platform holds, not the contents of the apps themselves. For employee-owned phones, the work profile boundary is what you rely on: managed apps and their configuration live on the work side, the personal copy of the same app is untouched. Document that boundary in the BYOD policy and have it signed.

Mistakes we see in deployments

1. No group structure. Everything assigned to "all devices", so every update is a fleet-wide event with no pilot and no staging.
2. Keystore on one laptop. We've seen a company lose the signing key of its own field-service app and rebuild it under a new package name, losing six months of local data.
3. Assuming the work profile behaves like a fully managed device. An uploaded APK that installs silently on company hardware may need the Managed Google Play private app route inside a work profile. Test both before you promise a date.
4. Forgetting GMS-free hardware. The rugged tablets arrive, the store doesn't work on them, and the project stalls. Ask the hardware vendor about GMS before you order.
5. Leaving the old sideloading path open. A managed catalogue and a download link in a shared drive, running in parallel, means you still don't know what's installed. Kill the link.

How Appaloosa does it

Appaloosa is built around a branded catalogue for public, private and web apps. You upload a signed APK or IPA, the platform versions it, you assign it to device groups, push updates silently and remove it remotely. Public apps arrive through Managed Google Play and Apple Business Manager in the same catalogue, the Managed Google Play connection is made during initial setup, and managed app configuration is applied at install time and can be updated later without a reinstall.

Internal builds also work on hardware without Google Mobile Services, which is why the catalogue carries both channels. Platforms covered: iOS, iPadOS, Android, Windows and macOS. For Android-specific policies, see Android MDM; for single-purpose devices locked to one app, kiosk mode sits in the same console. The infrastructure is hosted in France on SecNumCloud-qualified hosting. Details on the mobile application management page, and if you want the conceptual background first, read what an enterprise app store is.

FAQ

Can I publish a private app without it appearing in public Play search?

Yes. A private app is tied to your organisation ID, so it never shows up in public search or on a public store page. Only devices in your fleet see it, while Google still hosts, scans and serves the binary. Private apps published from an EMM console also aren't subject to the same review checks as public apps, which is part of why they're available in minutes.

Do users have to enable installs from unknown sources?

No, not on a device enrolled in Android Enterprise. The management agent installs approved apps silently, private builds included, and no permission screen appears. That prompt only shows up when someone installs a file by hand outside managed distribution, which is exactly the workflow a private store replaces.

What about iOS apps?

The same catalogue logic applies, with different plumbing. In-house iOS builds are distributed internally to enrolled devices with an enterprise signing certificate, and public apps come through volume licences in Apple Business Manager. One warning: a revoked enterprise certificate stops every app signed with it from launching, so certificate expiry dates belong in your calendar, not in a wiki page nobody opens.

Start with one app, one group of ten devices, and one week of observation. The technical work is an afternoon; the group structure and the update policy are what decide whether this still works when the fleet doubles.