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.
There are two ways you can distribute proprietary in-house apps:
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 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
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 organization can define whether to keep or remove a managed application upon unenrollment 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 Enrollment or account-driven Device Enrollment.
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
InstallEnterpriseApplication (manifest file or embedded manifest) or
InstallApplication (manifest file) commands. Prefer using the
InstallEnterpriseApplication command because it supports sha256 and certificate pinning. For more information, see MDM commands.
Use a website to distribute the app
For wireless app installation, iOS and iPadOS 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 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:
For Microsoft’s Internet Information Server (IIS), use IIS Manager to add the MIME types in the Properties page of the server:
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 an MDM solution.
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 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 or the iPadOS 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, 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.