The short answer
For an app only your employees use there are five routes on iOS, and the one you need is almost never the one people assume. The default is Custom Apps through Apple Business Manager: the app goes through App Review, doesn't appear in the public App Store, and is distributed to specific organisations via MDM or redemption codes. The Apple Developer Enterprise Program — the one everyone asks for — requires 100 or more employees and Apple reserves it, in writing, for cases the other routes don't cover. On Android the equivalent is a private app in managed Google Play, published in about ten minutes and not subject to the same checks as a public app.
This isn't a last-week decision: it changes the project. Choosing wrong means discovering, in launch month, that your identity model, your update model and even your signing setup were built for the wrong channel.
The five routes, and which one is yours
| Route | Who can install it | App Review | Production-ready |
|---|---|---|---|
| Public App Store | Anyone | Yes | Yes, but your internal app is exposed |
| Custom Apps (Apple Business Manager) | Organisations you authorise | Yes | Yes — the default case |
| Unlisted | Anyone with the direct link | Yes | Yes, with your own authentication |
| Enterprise Program | Only your organisation's employees | No | Yes, if you meet the requirements |
| Ad Hoc / TestFlight | Registered devices or testers | TestFlight, light review | No |
1 · Custom Apps: the default route
A Custom App exists in Apple's catalogue but is only visible to the organisations you specify. The client organisation gives you their Organization ID — found in Apple Business Manager under Preferences → Enrollment Information — and you mark the app as private in App Store Connect, under Pricing and Availability → App Distribution Methods → Private.
From there the organisation deploys it two ways: automatically via MDM to enrolled devices, or with redemption codes distributed however they choose.
Two things worth knowing up front, because both have cost teams weeks:
App Review still applies. A Custom App is reviewed like any other. If the app requires corporate authentication — and an internal app always does — you must provide test credentials and sample data to the reviewer. Without that, rejection is automatic and you lose the cycle.
The private option is only available before the app is approved. It isn't a switch you flip afterwards. If the app is already approved as public, changing it to private isn't a checkbox: it's redoing the path. That's why the channel decision belongs at project kickoff, not publication week.
2 · Unlisted: when the audience isn't your payroll
An unlisted app lives on the App Store but doesn't appear in search, categories, charts or recommendations. It's reached only through a direct link, and can also be served through Apple Business Manager or Apple School Manager.
It fits when the recipient isn't exactly your staff: franchisee networks, distributors, business partners, conference attendees, students on a programme. People who aren't in your MDM and whose devices you won't enrol.
How to request it: the app must already be on the App Store or have been submitted to App Review. You add a note in Review Notes declaring the intent and submit the unlisted distribution request. Apple declines the request if the app hasn't been submitted for review yet or if it's in a beta or prerelease state. Once approved, the setting applies to all future versions.
The important warning comes from Apple's own documentation: anyone with the link can download it. A link is not an access control. The app has to implement its own identity barrier, because the channel doesn't provide one.
3 · Enterprise Program: the last resort, and Apple says so
It's the programme everyone asks for first and the one Apple explicitly places last. The requirements, verbatim:
- 100 or more employees.
- Be a legal entity: no DBAs, fictitious business names, trade names or branches.
- Use the programme only for proprietary, in-house apps distributed privately to employees within the organisation.
- Have systems ensuring only employees can download them.
- Pass Apple's verification interview and continuous evaluation process.
- A D-U-N-S Number and a public website on your own domain.
It costs 299 USD per year. And Apple bounds its use with a sentence worth reading in full: the programme is "only for specific use cases that are not adequately addressed with public apps on the App Store, custom apps through Apple Business or Ad Hoc distribution, or beta testing through TestFlight".
Translated: if a Custom App covers your case, asking for the Enterprise Program means asking for the route Apple watches most closely and revokes fastest. In exchange you gain exactly one thing — skipping App Review — and accept two risks: continuous evaluation, and dependence on certificates that expire and that, mishandled, leave your entire workforce without the app on the same day.
4 · Ad Hoc and TestFlight are not distribution
Both come up in every conversation and neither is a production channel.
Ad Hoc requires registering each device by UDID, with an annual cap per device type. It works for a twenty-person pilot and breaks the day the second office joins.
TestFlight is beta testing: builds expire, testers are told they're in a trial, and the channel isn't meant for a work tool to live there indefinitely. That it technically holds up doesn't make it the right place.
Using them as permanent distribution is the decision that looks like a time-saver in month one and forces a redeployment in month nine, with the app already in people's hands.
5 · Android: managed Google Play and the fifteen a day
On Android the equivalent is the private app in managed Google Play: published and automatically approved for your organisation, with no public visibility.
Two ways to publish it. From the managed Google Play iframe built into your EMM console, where the title and the file (AAB or APK) are enough and the app is usually ready to distribute in about ten minutes. Or from Play Console, restricting targeting to your enterprise. Not every EMM supports the iframe, so that's the first thing to check.
The limits worth knowing before designing your release process:
- 15 private apps per day per organisation.
- Private apps aren't subject to the same checks as public ones. Hence the ten minutes.
- They can't be converted to public later.
- They're non-transferable between Play developer accounts.
That last point bites during mergers and supplier changes: if the private app was published under the wrong account, it doesn't move. You republish and redeploy.
The mistake that costs a month of calendar
The pattern repeats: the team builds the app assuming the public App Store, and late in the process someone asks how people will actually install it. From there, three unbudgeted workstreams appear.
Identity. A public app assumes signup; an internal one assumes the user already exists in the corporate directory. Switching between the two in the final month touches the whole onboarding, not just the login screen.
Updates. With MDM the admin controls deployment and it can be silent; with redemption codes or a link, people update if they feel like it. Your minimum-supported-version strategy and your data migrations depend on which, and that's an architecture decision.
Account ownership. The developer account must belong to the client, not the agency. It's the difference between being able to change supplier and not. We cover it separately in who should hold your app signing certificates, because it's the same family of problem.
When not to use each one
- Don't use the Enterprise Program if a Custom App solves your case. You take on continuous evaluation and revocation risk to skip a review you'd have passed anyway.
- Don't treat Unlisted as an access control. Links circulate; you provide the authentication.
- Don't use TestFlight as a permanent channel. Builds expire and users know they're in a beta.
- Don't use Custom Apps if your recipient has no Apple Business Manager. No Organization ID, no channel — and setting up ABM at the client is a project with its own timeline.
- Don't use a private Play app if you might ever want it public. It doesn't convert.
What to check before writing a line of code
Four questions, all of them week-one questions:
- Who installs the app: employees on managed devices, or people outside your MDM?
- Does Apple Business Manager exist at the client organisation, and who administers it?
- Whose name are the Apple and Google developer accounts in?
- Who decides when an update happens: the administrator or the user?
Answering these first shapes your identity, update and signing models. Answering them later means rebuilding all three.
Primary sources, consulted on 14 August 2026: Apple Developer Enterprise Program, Custom Apps, Unlisted App Distribution and private apps in managed Google Play.
