Distribute proprietary in-house apps to Apple devices
Apple devices support wireless installation of proprietary in-house apps without using a Mac or going through the App Store. Before you can distribute these apps, 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, see Install a Provisioning Profile on the Apple Developer website to create another profile for the app. For an iOS or iPadOS app, export a new app bundle (a .ipa file) with the new provisioning profile for users installing the app for the first time.
Provisioning and managing 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.
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.
Manage proprietary in-house apps for Mac computers
For a Mac with macOS 14 or later, you can manage more apps. If a package contains more than a single app bundle, any app that gets deployed into /Applications is managed. Managed Apps need to remain in the /Applications folder to be considered managed.
Using a device management service, an organization can define whether to keep or remove a Managed App upon unenrollment, or even uninstall an app using that service. This removes the app bundle from /Applications. Any data that the package or associated scripts installs in other locations remains untouched.
In addition, data of Managed Apps is located on a separate volume when using User Enrollment or account-driven Device Enrollment.
Provisioning and managing 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.
Get the bundle ID for a Mac application
To get the bundle identifier (also known as the bundle ID), Control-click the application, then select Show Package Contents. Open the Contents folder, then open the Info.plist file. If you aren’t sure which app to use, open the file in TextEdit. Use the app’s Find feature to find CFBundleIdentifier in the file, then copy the string below that line. For example, com.betterbag.applicationname. Paste the application bundle identifier into a text file, or into a note for later use.
Use a device management service to distribute the app
To use a device management service, you need to use a manifest with either the InstallEnterpriseApplication (manifest file or embedded manifest) command or the InstallApplication (manifest file) command. macOS also supports SHA-256 and certificate pinning. There are additional options when using these commands with different operating systems:
For devices with iOS 17.2, iPadOS 17.2, visionOS 1.1, or later, you can also use the declarative app configuration.
For a Mac, you can use:
The
InstallApplicationcommand for volume purchases and .pkg installs.The
InstallEnterpriseApplicationcommand for only .pkg installs.
For more information, see Device management commands.
Use a website to distribute the app
For wireless app installation, iOS, iPadOS, and visionOS 1.1 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 package, 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.
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.
Providing updated proprietary in-house apps
Apps you distribute yourself 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.
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.
If your distribution certificate expires, the app won’t launch and you’ll need to rebuild the app with a new distribution certificate. 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.
Troubleshooting 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.