Most internal business apps should never go on a public app store.

What a public listing costs a staff app

A public listing is a consumer product obligation. You write store copy, screenshots, a privacy policy URL and a support URL, you answer data safety questions, and strangers can install a tool built around your internal process. None of that makes the app better for the people who actually use it.

Review is the other cost, and it lands on the private routes too. A staff app behind a login wall gives a reviewer nothing to look at, so you have to hand over working credentials. Apple's custom app documentation says to provide sample data and authentication for the App Store Review team when the app contains sensitive data. That is the fix, and it is cheaper than arguing.

There is a cost people only notice later. A public listing collects public ratings for a tool nobody chose to use, and a one star review from a frustrated driver sits next to your company name. This is also where enterprise app development and a ten person operations app stop resembling each other. An internal tool mobile app carries none of the obligations a consumer launch does, and the paperwork does not scale down to fit it.

Apple gives you four ways in, plus one you probably should not use

In App Store Connect you choose between Public Distribution and Private Distribution. Private means the app is available only on Apple Business or Apple School Manager, to businesses you name. The documented path, read on 3 October 2026: Apps, your app, Pricing and Availability in the sidebar, then App Distribution Methods, select Private, then under Type choose either Organization ID or Apple Account. Account Holder, Admin or App Manager role required. The named organization distributes the app through Mobile Device Management or redemption codes and finds it in the Custom Apps section. Note the naming: Apple's current pages write Apple Business where older guides write Apple Business Manager, and they still allow assigning an app to an Apple Account for organizations on the legacy Volume Purchase Program.

Read Apple's note before you choose, because it is the whole reason this page exists. Once your app is approved, the distribution method cannot be changed. The only permitted move afterwards is public to unlisted. Going private to public, or public to private, means a new app record and a resubmitted binary.

Unlisted is the third route. The app sits on the App Store but appears in no category, chart, search result or recommendation, and only a direct link reaches it. Apple's unlisted app distribution page says the app must already be on the App Store, or be submitted to App Review, before you request a link. Requests are declined for apps in a beta or prerelease state. It suits franchisees and part-time staff on their own phones. It is not a way around review.

The fourth is Ad Hoc, which installs a signed build straight onto devices you have registered. Apple's account documentation puts the ceiling at 100 devices per product family per membership year. Disabling a device does not return the slot. The count only resets at the start of a new membership year. TestFlight sits beside it while the app is still moving: up to 100 internal testers who are App Store Connect users, and a build that becomes unavailable to testers after 90 days. The Apple Developer Enterprise Program is the route most people reach for and usually should not. It is 299 USD per membership year. It requires 100 or more employees, a legal entity, a D-U-N-S number and a verification interview. Apple's own page says the standard Apple Developer Program is the right option for most organizations distributing internal-use apps.

App Store Connect Help, Set distribution methods (read 3 October 2026)

Google Play calls the same thing a private app

On Android the staff-only route is a private app in managed Google Play. The documented path, read on 3 October 2026: Test and release, then Setup, then Advanced settings, then the Managed Google Play tab, then under Organizations click Add organization and enter each Organization ID with a description. Up to 1000 organizations per app. The app then becomes searchable and distributable inside each organization's EMM console within a few minutes. One warning: Google's Android Enterprise help still prints an older Release, Setup, Advanced settings path for the same screen, so follow the Play Console Help version.

The irreversible thing here is the package name, not the app record. Google's wording is blunt. Once your app is restricted to organizations it is private and available to those organizations only, and if you later want it public you must publish a new app with a different package name. The Organization ID comes from the receiving side, out of the EMM iframe under Organization details, which is also how an agency publishes an app into a client's organization.

The internal test track is the lighter option, and it is where most small staff apps should start. Up to 100 testers per app, added by email address or uploaded as a CSV, under Test and release, Testing, Internal testing, then the Testers tab. New builds reach testers within minutes. Testers in countries where your app is not otherwise available still get it, and Google says internal tests might not be subject to standard Play policy or security reviews. It is not a permanent home, but it is the fastest way onto a colleague's phone. Who sees what once they are inside the app is a different problem from who can install it, and app user roles permissions is where that gets decided.

One rule changed on 30 September 2026 and is already in force. Google's Android Enterprise documentation says private Android apps on unmanaged, Google Play Protect certified devices must be registered to a verified developer identity to stay installable and to keep receiving updates. Apps on fully managed devices, or inside a Work Profile, are exempt. So whether you can simply hand staff an APK now depends on whether you manage the phones. If you do not, you register the identity and the package name, which wants an organization account on a corporate domain email, a D-U-N-S number and the SHA-256 fingerprint of your signing key. An end user can also allow an unregistered private app through an advanced setting in Android developer options, which is not something to build a rollout plan on.

Google Play Console Help, Publish private apps (read 3 October 2026)

Pick the route before you build anything

The picker below asks the three questions and names a route on each platform. It leans conservative. Where managed devices are involved it points at the private route, because that is the only option here that survives staff turnover without someone recollecting UDIDs or email addresses every quarter.

Two things it cannot cover. First, account type. Register the Play developer account as an Organization, not a Personal one. Personal accounts created after 13 November 2023 must run a closed test before they can apply for production access: at least 12 testers, opted in continuously for 14 days. A private app ends in a production rollout, so that test stands in the way. Second, you need real hardware. A simulator will not exercise MDM enrolment, a managed Work Profile, push tokens or a camera-based barcode scan, which is most of what an operations app leans on. Budget one real device per platform and find that out early.

Then stop reading about distribution and go and do it once. The Android side in particular is best learned on a throwaway package name, and distributing it to staff only is a short procedure once the account type is right.