Apple Enterprise Distribution Solution Mytime Target

iOS Enterprise Distribution for Internal Tools: What Actually Works

If you're trying to push a custom iOS app to your organization's devices without using the public App Store, the Enterprise Distribution Program is still the standard route. It's not perfect, but it's the only clean way to handle large-scale internal deployments. The process involves generating an enterprise certificate, provisioning profiles, and hosting the .ipa file somewhere your servers can reach it. You then point devices at an HTTPS endpoint with a manifest.plist file that describes the app. I've been setting up enterprise deployment pipelines for about six years now, mostly for internal business tools and compliance apps that need to stay within organizational networks. The core workflow is straightforward if you know where the pain points actually are. First, you need an Apple Enterprise Developer Account. These cost $299 annually like the regular program, but they come with significantly more restrictive terms. Your app must be genuinely internal — used by employees on company devices for business purposes. Apple has been cracking down on misuse lately, so don't even think about distributing anything outside your organization. They revoke certificates faster than they issue them when they catch violations.

The technical setup starts with Xcode. Create your app target, set the bundle identifier, and make sure you're building with the correct provisioning profile. Apple requires codesigning with the enterprise certificate, not the development or ad-hoc certificates. Export the .ipa through Xcode's archive system using the "Enterprise" distribution method. If you skip this step and export as App Store, the resulting .ipa won't install on any device outside the public App Store flow. Next, you need a manifest.plist file. This is the piece that actually drives the installation process. It contains the URL to your .ipa, the app's bundle identifier, version information, and a title that users see during installation. Here's what it looks like:

Host this file on a server with HTTPS. Apple requires TLS 1.2 minimum, and self-signed certificates will block installation on most devices. Your .ipa file needs to be served from the same or a similarly configured server. HTTP endpoints simply won't work anymore — Apple removed that support years ago. Device enrollment happens through a simple link. When you send your users this URL format, it triggers the installation prompt automatically: https://your-server.com/install.plist

Users tap the link on their iPhone or iPad, confirm they trust the enterprise certificate when prompted, and the app installs. You're done. No approval process. No App Store review. Just click and go. Here's where things get tricky. I spent three weeks debugging an issue with a client's deployment where half their users couldn't install the app. The .ipa was valid, the manifest looked correct, and the server was responding properly. The problem turned out to be the provisioning profile. Apple requires the provisioning profile embedded in the .ipa to explicitly allow all target devices, or at minimum have the profile set to "Any Device" in the entitlements. My client had created a provisioning profile with specific device IDs, which works fine for Ad Hoc distribution but causes silent failures with enterprise distribution because the profile gets validated against the enterprise agreement terms. Switched to a general enterprise profile and the issue resolved immediately. Another thing nobody warns you about: certificate revocation. Apple will revoke your enterprise certificate if they detect your app is being distributed outside the intended organization. This happens through various signals — users reporting your app, unusual download patterns, or apps appearing on third-party distribution sites. When revocation occurs, all previously installed apps will stop launching on day one. You can't fix it. The only option is to apply for a new certificate and redeploy everything.

For tracking purposes, I've seen some organizations use backend analytics to log installation events. You can embed a call in your manifest that reports back to your server when installation completes. This helps you verify that distribution is reaching the right audience and gives you data for compliance audits. Some teams also use MDM solutions like Jamf or Kandji alongside enterprise distribution for better device management and app lifecycle control. The main alternatives to consider are: using the public App Store with restricted access (requires users to have personal Apple IDs and go through approval), setting up your own app distribution platform with certificate management (requires significant infrastructure investment), or moving to Android entirely if your organization is open to it (enterprise distribution on Android is simpler and has fewer restrictions). None of these are better for most internal tool scenarios, but they're worth evaluating if your current setup isn't working. Deployment times vary. A clean enterprise build from start to finish typically takes 20-40 minutes for the first release, including certificate generation, build, manifest creation, and server configuration. Subsequent updates drop to about 10-15 minutes if your pipeline is automated. Manual processes can stretch this to two hours or more, so invest in automation early.

One final note: keep your certificates secure. Store them in a hardware security key or encrypted vault. If someone gets access to your enterprise certificate, they can sign and distribute apps on behalf of your organization without your knowledge. I've seen this happen, and the fallout is messy — both from Apple's perspective and yours.