
Distribute proprietary in-house apps to Apple devices
Apple devices support wireless installation of proprietary in-house apps without going through the App Store using the Apple Enterprise Developer Program. The Apple Developer Enterprise Program is only for the internal use and distribution of proprietary apps in specific use cases that are not adequately addressed with public apps on the App Store, Custom Apps through Apple School Manager or Apple Business Manager, Ad Hoc distribution, or beta testing through TestFlight.
For more information, see the Apple Developer Enterprise Program.
Provisioning profile
Before you can distribute proprietary in-house apps to iPhone, iPad, Apple TV, Apple Vision Pro, and Apple Watch devices, you need to have a provisioning profile. You can install and manage provisioning profiles using a device management service, and then users can download and install them through that service or an app update.
Before a provisioning profile expires, create a new profile for the app through the iOS Developer website, the iPadOS Developer website, or the visionOS Developer website. Export a new app bundle (a .ipa file) with the new provisioning profile for users installing the app for the first time.
If users already have the app, you may want to time your next released version so that it includes the new provisioning profile. In this way, users won’t be interrupted doing work with your app. If not, you can distribute just the new .mobileprovision file, so users won’t have to install the app again. The new provisioning profile overrides the one already in the app archive.
Distribution provisioning profiles expire 12 months after they’re issued. After the expiration date, the profile is removed and the app won’t launch.
Provision and manage users for proprietary in-house app developers
Proprietary in-house app developers have access to Apple APIs for provisioning and managing users, allowing them to automate tasks such as provisioning profile generation and integrating user management into existing workflows.
For more information, see Enterprise Program API on the Apple developer website.
There are two ways you can distribute proprietary in-house apps:
Using a device management service
Using a website
Both of these methods require preparing the app for distribution, which includes the preparation of a manifest.
Important: For devices with iOS 18 and iPadOS 18, or later, proprietary in-house apps that you manually install (not using a device management service) require a device restart to complete the trust of the provisioning profile.
Prepare a proprietary in-house app for wireless distribution
To prepare your proprietary in-house app for wireless distribution, you build an archived version (an .ipa file), and a manifest file that enables wireless distribution and installation of the app. Use Xcode to create a versioned archive of your app, and then export the app for distribution to the organization. Xcode uses the distribution certificate and includes the appropriate provisioning profile. The manifest file is an XML property list (a .plist file) used by Apple devices to find, download, and install apps from your web server. The manifest file is created by Xcode, using information you provide when you share an archived app for distribution to an organization. To view the list of attributes and associated values, see the Install Application command on the Apple Developer website.
Use a device management service to distribute the app
To use a device management service, you need to use the prepared manifest file with one of the following:
Declarative app management available on iOS 17.2, iPadOS 17.2, visionOS 1.1, or later.
The
InstallEnterpriseApplication
command (manifest file or embedded manifest) command.The
InstallApplication
command (manifest file)
Use a website to distribute the app
For wireless app installation, iOS, iPadOS, and visionOS, apps need to meet the following requirements:
Apps need to be in .ipa format and be built with an in-house provisioning profile.
They need to have an XML manifest file.
They need to be downloaded from a website whose address begins with HTTPS.
They need to be signed by a certificate that’s trusted on the device.
Their network configuration needs to allow devices to access a server at Apple. For more information, see the Apple Support article Use Apple products on enterprise networks.
To install the app, users download the manifest file from your website using the special URL prefix. You can distribute the URL for downloading the manifest file by iMessage or a mail message. Here’s a sample link with the prefix added:
<a href="itms-services://?action=download-manifest&url=https://betterbag.com/manifest.plist">Install App</a>
It’s up to you to design and host the website used to distribute these type of apps. Make sure that users are authenticated and that the website is accessible from your intranet or the internet, depending on your needs. Your website can be a single page that links to the manifest file. When a user taps a web link, the manifest file is downloaded, which triggers the downloading and installation of what your webpage has described.
Make sure you follow this additional guidance:
Don’t add a web link directly to the archived app (.ipa). The .ipa file is downloaded by the device when the manifest file is loaded. Although the protocol portion of the URL is “itms-services,” the App Store isn’t involved in this process.
Be sure that the .ipa file is accessible over HTTPS and that your site is signed with a certificate that’s trusted by iOS and iPadOS. Installation fails if a self-signed certificate doesn’t have a trusted anchor and can’t be validated by the device.
Upload these items to an area of your website that your authenticated users can access:
The manifest file (with a .plist filename extension)
The app file (with a .ipa filename extension)
You may need to configure your web server so the manifest file and app file are transmitted correctly. For the server, add the MIME types to the web service’s MIME types settings:
application/octet-stream ipa
text/xml plist
For Microsoft’s Internet Information Server (IIS), use IIS Manager to add the MIME types in the Properties page of the server:
.ipa application/octet-stream
.plist text/xml
Note: If you create a self-service portal, consider adding a Web Clip to the user’s Home Screen so it’s easy to direct them back to the portal for future information, such as new configuration profiles, recommended App Store apps, and allowing them to enroll in a device management service.
Certificate validation
The first time a user opens an app, the distribution certificate is validated by contacting the Apple OCSP server. If the certificate has been revoked, the app won’t launch. To verify the status, the device needs to be able to reach ocsp.apple.com.
The OCSP response is cached on the device for the period of time specified by the OCSP server—currently between 3 and 7 days. The validity of the certificate isn’t checked again until the device has restarted and the cached response has expired. If a revocation is received at that time, the app won’t launch.
Your distribution certificate is valid for 3 years from when it was issued or until your Apple Developer Enterprise Program membership expires, whichever comes first. To keep your certificate from expiring, be sure to renew your membership before it expires.
You can have two independent distribution certificates active at the same time, with each independent from the other. The second certificate provides an overlapping period in which you can update your apps before the first certificate expires. When you request your second distribution certificate, be sure not to revoke your first certificate.
WARNING: Revoking a distribution certificate invalidates all of the apps you’ve signed with it. You should revoke a certificate only as a last resort—if you’re sure the private key is lost or you think the certificate has been compromised.
Manually update proprietary in-house apps
For proprietary in-house apps distributed using a device management service, you can use the Managed App mechanism to update an app.
If users have downloaded them manually, apps aren’t automatically updated. When there’s a new version, notify users of the update and instruct them to install the app. Consider having the app check for updates and having it notify the user when the app opens. Make sure the notification provides the itms-services link. You can also use openURL from within the app to install the update.
If you want users to keep the app’s data stored on their device, make sure the new version uses the same bundle identifier as the one it’s replacing, and tell users not to delete their old version before installing the new one.
Troubleshoot wireless app distribution
If wireless app distribution fails with an “unable to download” message:
Make sure the app is signed correctly. Test it by installing it on a device using Apple Configurator for Mac, and see if any errors occur.
Make sure the link to the manifest file is correct and the manifest file is accessible to web users.
Make sure the URL to the .ipa file (in the manifest file) is correct and the .ipa file is accessible to web users over HTTPS.