MDM and private distribution for operator apps: Intune, JamF, and Apple Business Manager
Operator apps don't belong on the App Store
App Store distribution is appropriate for consumer apps and B2B apps with self-serve installation. It is the wrong channel for operator apps that ship to a known fleet of corporate-owned devices, with mandatory configuration, with security baselines the public store can't enforce, and with audit requirements that public-store install paths don't satisfy.
Putting an operator app on the App Store creates problems instead of solving them. The wrong customer downloads it. App Store reviews aren't the operator's voice. Configuration has to ship via separate flows. The correct architecture for operator apps is MDM-based private distribution, where the security team chose the channels and already operates them.
Apple Business Manager is the iOS path for operator apps
Apple Business Manager (ABM) is Apple's enterprise distribution surface. The customer's organization has an ABM tenant; we publish the app as a Custom App scoped to that tenant; the customer purchases or licenses copies through ABM; the MDM (Intune, JamF, Workspace ONE) deploys the app to managed devices with the correct configuration. The app never appears in the public App Store. Only the customer's managed devices can install it.
ABM Custom Apps support managed app configuration — the MDM pushes a key/value configuration to the app at install time, so server URLs, authentication endpoints, feature flags, and tenant identifiers arrive without the user typing them. We integrate this from week one in our mobile engagements; retrofitting managed configuration into an app that wasn't designed for it is painful.
- Distribution channels
- 4 ABM, Intune, JamF, Workspace
- Time to install
- < 5 min from MDM push to first launch
- Managed-config keys
- ~15–30 per operator app
- Public-store exposure
- 0 app never published publicly
Microsoft Intune is the most common MDM for enterprise customers
Most enterprise customers we work with run Intune as their MDM. The deployment flow: the iOS build is licensed through Apple Business Manager and assigned to Intune; the Android build is published as a Managed Google Play app and assigned to Intune; both deploy to managed devices through Intune policies that enforce installation, configuration, and lifecycle.
Intune-specific patterns matter: app protection policies enforce data-loss prevention controls (no copy/paste to non-managed apps, mandatory app-pin), conditional access ties app launch to device compliance, and selective wipe removes the app and its data without touching the rest of the device when an employee leaves. We design operator apps to honor each of these controls explicitly.
JamF is common in healthcare and creative-heavy organizations
JamF Pro and JamF School are heavily used in healthcare systems, education, and Apple-first creative organizations. The deployment shape is similar to Intune — ABM licensing into JamF, MDM push to managed devices, configuration through managed app config — with JamF-specific policy primitives and a different administrative experience.
We've shipped operator apps through JamF for clinical workflows where the iPad is the primary device. The integration testing covers JamF's specific configuration delivery, restriction profiles, and integration with the customer's identity provider. Each MDM has quirks; we test against the customer's actual MDM rather than a generic baseline.
Google Workspace and Managed Google Play handle Android private distribution
On Android, the equivalent of ABM is Managed Google Play. The app is published as a private listing scoped to the customer's organization; it is installable only on devices enrolled in the customer's Workspace tenant. Configuration via managed configurations, app distribution via Workspace policies, and lifecycle via Android Enterprise APIs all work analogously to the iOS side.
Android device fleets in operator contexts are usually a mix of Android Enterprise (work profile or fully managed), zero-touch enrollment for new devices, and rugged-device fleets with manufacturer-specific MDM extensions. We test the operator app against the customer's actual fleet composition, not a clean Pixel-only baseline.
Authentication should integrate with the corporate IdP, not require a separate password
Operator-app users are corporate employees with corporate identity. The right architecture is OIDC integration with the customer's identity provider (Entra ID / Azure AD, Okta, Google Workspace), with single sign-on through the iOS or Android system identity if available. Asking operators to maintain a separate password for the operator app is operational friction the customer's security team will reject.
Token storage uses the platform secure enclave on iOS (Keychain with Secure Enclave references) and Android Keystore. Refresh tokens are short-lived; access tokens are scoped narrowly. The MDM can revoke access at the device or user level, and the operator app respects that revocation on next launch.
Lifecycle management — onboarding, off-boarding, version control — is where MDM earns its keep
When a new operator joins, MDM enrollment triggers app installation and configuration delivery. When an operator leaves, MDM revokes access and selective-wipes the app. When the app updates, MDM controls rollout cadence and can stage the new version to a percentage of the fleet before universal deployment. None of this is possible through public-store distribution.
The MDM is the lifecycle plane. The app integrates with it through standardized hooks (managed app configuration, app protection policies, restriction respect) and through customer-specific MDM scripts where appropriate. We document the integration points so the customer's IT team can manage the lifecycle without depending on us for routine operations.
We tried to publish the operator app on the App Store first because it was the path we knew. Three rejections later, all for reasons that didn't apply to a B2B operator app, we switched to ABM Custom App distribution. The security team had been telling us to do that from week one. They were right.
— VP Product, field-service deployment
Frequently asked
Why not put an operator app on the App Store or Play Store?
Because operator apps ship to a known fleet of corporate-owned devices with mandatory configuration, security baselines the public store can't enforce, and audit requirements public-store install paths don't satisfy. Public stores are right for consumer apps and self-serve B2B. For operator apps, MDM-based private distribution is the architecturally correct channel — and it's the channel the customer's security team already operates.
What is Apple Business Manager and how does Custom App distribution work?
ABM is Apple's enterprise distribution surface. The customer's organization has an ABM tenant; the app is published as a Custom App scoped to that tenant; the customer licenses copies through ABM; the MDM deploys the app with managed configuration. The app never appears in the public App Store and only the customer's managed devices can install it. Managed app configuration delivers server URLs, OIDC endpoints, and feature flags at install time.
Which MDM do most enterprise customers use?
Microsoft Intune is the most common in enterprise environments, JamF in healthcare and Apple-first creative organizations, Google Workspace for Android-heavy or Workspace-native shops. We test operator apps against the customer's actual MDM rather than a generic baseline. Each has specific policy primitives — app protection, conditional access, selective wipe, restriction profiles — that the operator app has to honor explicitly.
How does private distribution work on Android?
Through Managed Google Play. The app is published as a private listing scoped to the customer's organization; it is installable only on devices enrolled in the customer's Workspace tenant. Managed configurations, app distribution via Workspace policies, and lifecycle via Android Enterprise APIs all work analogously to the iOS side. Android Enterprise enrollment supports work-profile, fully-managed, and zero-touch device modes.
How is authentication handled in operator apps?
Through OIDC integration with the customer's identity provider — Entra ID, Okta, Workspace — with SSO through system identity where available. Tokens are stored in platform secure enclaves (Keychain with Secure Enclave on iOS, Android Keystore on Android). Refresh tokens are short-lived; access tokens are scoped narrowly. The MDM can revoke access at device or user level, and the operator app respects revocation on next launch.
What does MDM lifecycle management cover?
Onboarding (enrollment triggers installation and configuration), off-boarding (selective wipe and access revocation), version control (staged rollout, percentage-based deployment, forced updates for security-critical releases), and configuration drift (the MDM re-applies the correct configuration when device state diverges). The MDM is the lifecycle plane; the app integrates through standardized hooks. The customer's IT team manages routine lifecycle without depending on us.
More from Field Notes
All essays
Mobile Native, React Native, or Flutter: the honest 2026 mobile platform answer
Native iOS/Android, React Native, Flutter — which to pick in 2026, when each wins, and the integration tradeoffs that decide it for operator apps.
Mobile Offline-first mobile sync with audit trails and last-write-wins conflict resolution
How to design offline-first mobile sync for field operators — local SQLite, CRDT-style conflict resolution, audit trails, and resumable upload queues.
Mobile Push notifications that respect the user: tiering, quiet hours, and deep linking
How to design push notifications that operators don't mute — APNs and FCM architecture, severity tiers, quiet hours, and deep links that land in the right surface.