Shipping Expo Apps to Enterprise MDM Environments

Key facts, with sources

• 71% of State of React Native 2024 respondents reported using Expo's EAS Build, ahead of manual builds with Xcode (59.7%) and Android Studio (54.5%). (InfoQ)
• Expo SDK 52, released November 12, 2024, enabled the New Architecture by default for all new projects, and Expo Go for SDK 52 and higher supports only the New Architecture. (Expo Changelog)
• The official React Native documentation now recommends starting new apps with a framework, naming Expo, rather than initializing a bare project. (React Native documentation)
• EAS build caching can speed up subsequent Android and iOS builds by up to 30% and is available to all users at no additional cost as of the SDK 57 cycle. (Expo Changelog)
• Doctolib runs Expo tooling without EAS to scale developer experience on a healthcare app serving 90 million users, showing Expo's open-source tools work independently of its paid cloud services. (Doctolib Engineering (Medium))

Distribution paths, ranked

For iOS, the path I recommend first is Apple Business Manager with custom (unlisted or private) app distribution: the app goes through App Store review but is visible only to the organizations you designate, and their MDM pushes it to enrolled devices. It's the most durable option because it doesn't hinge on certificate renewals or device registration ceilings. The Apple Developer Enterprise Program — in-house signing with an enterprise certificate — still exists but Apple has tightened access, and a revoked or expired enterprise cert takes the entire fleet down at once, so I treat it as the fallback, not the default.

Android is simpler: managed Google Play supports private apps published to specific organizations, and most MDMs integrate with it directly. Direct APK sideloading via MDM works too, but you give up Play's update mechanics, so I only take that path when the client's policy forbids Play entirely.

EAS configuration for enterprise builds

On the build side, this is a dedicated eas.json profile. Internal distribution produces installable artifacts outside the public stores, and for iOS enterprise-certificate signing, EAS supports enterprise provisioning as a first-class credential option. I keep the enterprise profile on its own update channel so corporate deployments never receive OTA bundles intended for the consumer app — in regulated environments, that separation is frequently an explicit audit requirement.

One practical note: keep the enterprise Apple team and credentials in EAS as a separate credential set from your standard distribution identity. Mixing them is the most common way I've seen teams accidentally sign a store build with an enterprise cert or vice versa.

{
  "build": {
    "enterprise": {
      "distribution": "internal",
      "channel": "enterprise",
      "ios": {
        "enterpriseProvisioning": "universal"
      }
    }
  }
}

OTA updates under security review

Expect the client's security team to flag EAS Update the moment they understand it: code arriving on managed devices without passing their change-control process is exactly what MDM policies exist to prevent. Don't dodge the conversation — walk in with the controls documented. Updates are signed and scoped to runtime versions and channels; the enterprise channel can be restricted so only explicitly approved updates are published to it; and expo-updates supports code signing so the binary verifies update authenticity against your certificate.

Some organizations will accept OTA under those controls, often with a requirement that updates go through their CAB process. Others will prohibit it outright — in which case you disable update checks for the enterprise build and every change ships as a new MDM-distributed binary. Build your release process assuming you'll need to support both modes across different customers, because you will.

Managed app config and network realities

Enterprise buyers frequently expect managed app configuration — the MDM pushing per-organization settings like server URLs or tenant IDs into the app. On iOS this arrives via managed defaults; on Android, through the managed configurations mechanism. There's no first-party Expo module for this, so plan for a small native module or a maintained community library, plus a config plugin if entitlements or manifest entries are needed. Scope it early; it's a small task that becomes an awkward surprise the week before a pilot.

The other recurring surprise is the network. Corporate environments run TLS-inspecting proxies, and apps using certificate pinning will fail behind them until the proxy's CA is accommodated or pinning is scoped. Test on an actual managed device inside the client's network before the rollout date — half the enterprise deployment issues I've debugged were proxy interference, not app bugs.

The compliance paperwork you can prepare in advance

MDM deployments come with security questionnaires, and Expo-specific questions recur predictably: where are builds executed, who holds signing credentials, what third-party services does the app contact at runtime, and what telemetry does the tooling itself send. Prepare a one-page data-flow document covering EAS Build infrastructure, the update service if you're using it, push notification routing if applicable, and your crash reporting vendor. Having this ready collapses weeks of security-review back-and-forth.

Also decide up front who owns the Apple Business Manager or managed Play relationship — you or the client. My strong preference is the client owns their organizational accounts and grants access, so the app's distribution doesn't depend on a vendor relationship. It's the arrangement that survives contract transitions, and enterprise procurement teams respond well to a vendor who proposes it unprompted.

When to hire senior help

Senior help pays off when deciding between managed and prebuild workflows, setting up EAS-based CI/CD and OTA update channels, or untangling a project that was ejected prematurely. An experienced Expo engineer can usually configure build, submit, and update pipelines in days, a task that costs first-time teams weeks of trial and error. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Expo Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Ejecting to the bare workflow at the first native requirement instead of using config plugins and development builds, permanently giving up managed upgrades
• ✕Testing only in Expo Go and misconfiguring runtime versions for expo-updates, so an OTA update ships JavaScript that crashes against mismatched native binaries
• ✕Burning EAS build minutes on every commit in CI without caching or local builds, turning a convenience service into a surprise line item
• ✕Skipping several SDK upgrades in a row, then being forced into a large breaking migration when app store target API level deadlines arrive

Frequently asked questions

Sources

• InfoQ
• Expo Changelog
• React Native documentation
• Expo Changelog
• Doctolib Engineering (Medium)