A Private iPhone App for Staff or Partners: Custom Distribution or an Unlisted Link?

Before commissioning an iPhone app for a limited audience, decide how that audience will obtain it. An app available to named organisations through Apple's organisational distribution is not the same as an unlisted App Store app that anyone with its link can reach. Neither choice, by itself, defines who may sign in or read your business records.

Start with the people and devices, not the phrase “internal app.” A managed company phone, an employee's own phone and a partner organisation can need different installation arrangements. Record the intended audience and ask the developer to confirm a supported distribution route before promising a rollout date.

When the audience is a set of organisations

Apple's custom-app distribution guidance describes making an app available to specific organisations in Apple Business or Apple School Manager. The developer identifies the organisations, which can then distribute the app using mobile device management or redemption codes.

This can be relevant to a proprietary workflow or a tailored app supplied to particular business partners. However, “we know the customers” is not a complete deployment plan. Identify the recipient organisations, who administers their distribution and what their users actually need to do to receive the app. Confirm the necessary organisational setup rather than assuming every partner already has it.

Apple's instructions say the private distribution choice is available before the app has been approved. Include it in the release plan early. The same guidance describes App Review and providing sample data and authentication for review when the app contains sensitive data. Use an appropriate review environment, not live confidential business records.

When users need an ordinary install link

Apple's unlisted-app guidance describes an App Store app discoverable through a direct link rather than categories, charts, recommendations or search listings. It includes managed and unmanaged devices and gives employee-owned devices as one possible use case.

The important limit is explicit: unlisted apps are available to anyone with access to the link. A link forwarded to an unintended recipient is not equivalent to a named-organisation distribution list. Avoid describing an unlisted app as “only our employees can install it” unless a separate, supported restriction actually establishes that result.

An unlisted route can be useful where a narrow audience needs a normal App Store installation experience without public discovery. It does not turn the link into a reliable secret. Design account eligibility and data access independently, even if the app has no search listing.

Do not use unlisted distribution as a beta shortcut

Apple requires an app requested for unlisted distribution to be already on the App Store or ready for final distribution and submitted to App Review. Its guidance says requests are declined for beta or prerelease apps or apps not submitted for review.

Therefore keep testing, review readiness and distribution approval as separate milestones. A developer demonstrating an installable test build has not proved that the final distribution route is approved. Do not promise staff a production rollout simply because a request has been submitted.

Changing direction can also require more than a switch. Apple's unlisted guidance says an app currently distributed privately to specific organisations needs a new App Store Connect app record, an uploaded binary and the public distribution setting before the unlisted request. Treat a later migration as a separately planned operation, not an assumed reversible toggle.

Installation and business access need separate acceptance

For your app, agree what happens after installation. Does the person sign in with an approved organisation account, accept an invitation or wait for staff approval? What happens when the person leaves or the partner relationship ends? Define the app's actual access controls rather than assuming distribution removes an installed copy or revokes its existing session.

Also name who owns the release and update process. Your handover should record the chosen distribution route, participating organisations where relevant, the responsible administrators and how a new approved user gets started. Keep this operational documentation separate from credentials and signing secrets; those should not be copied into an ordinary project brief.

These are proposed project requirements, not promises that Apple's distribution tools implement your entire joiner-and-leaver process.

Test the route your audience will use

Arrange an authorised test with the intended device and account setup. For an organisational route, demonstrate receipt through the recipient's actual distribution process. For an unlisted route, check the approved link on the intended managed or unmanaged device. Neither test should require a real customer's confidential records.

Then test a permitted user and a harmless account that should not access the business data. Record installation, sign-in eligibility and data visibility separately in the acceptance criteria. A successful installation is only the first of those results.

Bring the audience and device arrangements to your mobile-app project discussion. The useful deliverable is an app that the intended people can obtain and use through a supported route, with honest limits on discovery and access. It is not merely a link labelled “private.”