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 must have a provisioning profile. Provisioning profiles can be installed and managed using a mobile device management (MDM) solution and then downloaded and installed by users through MDM or an app update. Before a provisioning profile expires, see the Apple Developer website to create a new 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 MDM
Using a website
Both of these methods require preparing the app for distribution, which includes the preparation of a manifest.
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 organisation. 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 organisation. 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
Starting with macOS 14, you can manage more applications. If a package contains more than a single application bundle, any application that gets deployed into /Applications is managed. Managed Apps must remain in the /Applications folder to be considered managed.
Using MDM, an organisation can define whether to keep or remove a managed application upon unenrolment or even uninstall an application using MDM. This removes the application bundle from /Applications. Any data installed by the package or associated scripts in other locations remains untouched.
In addition, data of managed applications is located on a separate volume when using User Enrolment or account-driven Device Enrolment.
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 MDM to distribute the app
To use MDM, use a manifest with either the InstallEnterpriseApplication (manifest file or embedded manifest) command or the InstallApplication (manifest file) command. macOS also supports sha256 and certificate pinning. There are additional options when using these commands with different operating systems:
On devices using iOS 17.2 or iPadOS 17.2, or later, you can also use the declarative app configuration.
On devices using macOS, you can use:
The
InstallApplicationcommand for volume purchases and .pkg installs.The
InstallEnterpriseApplicationcommand for only .pkg installs.
For more information, see MDM commands.
Use a website to distribute the app
For wireless app installation, iOS, iPadOS and visionOS 1.1 apps must meet the following requirements:
Apps must be in .ipa format and be built with an in-house provisioning profile.
They must have an XML manifest file.
They must be downloaded from a website whose address begins with HTTPS.
They must be signed by a certificate that’s trusted on the device.
Their network configuration must 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 types 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 web page 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.
Make sure 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 enrol in an MDM solution.
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 must 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 for it to 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 expiry 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 three years from when it was issued or until your Apple Developer Enterprise Programme 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, make 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.