App Distribution Guide: Deploying Apps on Apple Devices

Deploying apps to Apple devices is a fundamental job for any admin, but it isn’t a trivial one. That’s because there are several pathways to acquiring those apps, and you need to figure out which one makes the most sense for your use case and your users. 

For iOS, iPadOS, tvOS, and macOS, there are several distinct categories of apps, based on how they’re distributed: App Store apps (which can be either public or unlisted); custom apps; and in-house apps. Then there’s another option just for macOS: Downloading directly from a developer or vendor.

Before we can start sorting through those options and make any recommendations about which one is right for you, we need to clarify the terms, to develop a standard nomenclature when it comes to the Apple software ecosystem. That way, when you talk to a developer, Apple, or an MDM provider such as Kandji about app distribution, you can all be on the same page.

App Store Apps

These are the apps that every Apple user knows and loves, the ones they purchase and download from Apple’s App Store. They’re the ones we all have on our personal devices, the ones we all use every day.

These apps are written by members of the standard Apple developer program, who pay $99 a year for the privilege. They submit apps to Apple’s App Review team via App Store Connect; when they do so, they can specify that they’ll be using the public distribution method, which makes apps available to any shopper in the App Store. 

(Ideally, they also select the option to make their app available in every country where Apple does business; limiting the geographic distribution of an app makes life harder for multinational businesses that need to deploy apps to employees all over the world.) 

Enterprise buyers can purchase App Store apps on behalf of their users in Apple Business Manager: They select the number of licenses they want and then sync those licenses with their chosen MDM solution. (Caveat: You can’t use Apple Business Manager and MDM to distribute apps that rely on in-app purchases or subscriptions; they must be fully paid or free.) 

Unlisted Apps

There’s a variation on App Store apps that Apple launched in early 2022: Unlisted apps are distributed through the App Store, but they’re hidden from the general public and can’t be found by search. Instead, a user needs to have the app’s full App Store URL to find and download them.

Unlisted apps are useful primarily when an organization wants to make a bespoke app available to users whose devices aren’t managed by the organization’s MDM solution. One typical scenario: A hospital wants to distribute an app they created to the healthcare professionals who work there. Those professionals might work for multiple medical clinics or hospitals, each with their own apps. Even if those users wanted to, they cannot enroll their personal devices in more than one MDM at a time. So those hospitals cannot use MDM to distribute those apps.

Unlisted apps solve this problem: They allow for apps that aren’t available to the general public but aren’t tied to a specific organization ID or MDM solution. The hospitals could provide the app’s URL to those users, perhaps by posting it on an internal website. (Securing the app’s content can be done with user authentication.)

Unlisted apps are also very helpful to avoid confusion when a developer needs to provide an app for a specific use case that isn’t suitable for everyone. 

For example, an accessory company might be making the switch from wired to wireless accessories. It would need to overhaul its App Store app to focus exclusively on its newer wireless products. Using unlisted app distribution, it could keep the app for its older wired accessories available, listing the URL for the unlisted app on a support page. Users could install the app directly on their devices with their Apple IDs. Larger customers could add the app to their Apple Business Manager instances and MDM solutions by entering the unlisted app URL in the Apps and Books search field.

Custom Apps

These are apps that are in the App Store, but private, meaning they are accessible only to specific customers and organizations. They’re developed either by an organization itself or by a developer on the organization’s behalf. Sometimes these are variations of publicly available App Store apps that have been personalized for specific markets, customers, or verticals. 

There’s often some confusion about how to refer to such apps. Among admins, they’re sometimes (erroneously) referred to as “B2B,” “private,” or “internal” apps. But the proper name, according to Apple, is custom apps.

For developers, the experience here is very similar to public apps: they join the same development program, pay the same developer fee per year, and specify the same geographic distribution options as they would for publicly available apps. The big difference: When it comes time to publish the app, the developer selects private distribution instead of public and then supplies the Apple Business Manager organization IDs of customers so the app can be added to their Apple Business Manager instances.

Once that's done, the organization can sign in to its Apple Business Manager instance, purchase the app, and sync it to its MDM—just like a regular App Store app. That means that you’re acquiring licenses to apps you created or commissioned. Typically, organizations have a separate arrangement for payment to the developer; within Apple Business Manager, custom apps are priced at $0. When you buy such an app for your organization, it’ll appear in a Custom Apps section of the Apple Business Manager nav bar. 

(Note: Kandji has a feature called Custom Apps, which is a different thing. Those are for Mac only, and are not from the App Store. With Kandji Custom Apps, you upload a zip file, a disk image with an app bundle at the root of the disk image, or a custom package you’ve built yourself or downloaded from another source such as a vendor.)

In-house Apps

Like custom apps, this channel has gone by many names over the years: “IPA,” “private,” “proprietary,” “internal-only,” and “enterprise” apps, among others. But the proper name, the one Apple uses officially, is in-house apps. 

To develop an in-house app, you must join the entirely separate Apple Developer Enterprise Program (ADEP), which costs $299 a year. When you apply to that program, you need to justify why the options above won’t work for you. You also need to attest that the apps you’ll develop are intended solely for employees of your organization and that you won’t distribute them elsewhere. (An exception is made for contractors.) Your organization must have a minimum of 100 employees. 

Throughout the signup process, Apple encourages you to opt for custom apps instead, touting the benefits of its official app-distribution channels. If you say you want to create in-house apps in order to test beta versions with employees or other early-access groups, you’ll be encouraged to use TestFlight instead.

If you confirm that an in-house app is the only way to go, once you are in the program you will be able to create your app and upload it to your MDM solution for deployment to your devices (assuming that solution offers an app-hosting option).

If your MDM solution does not offer such hosting (but still supports in-house app distribution), or if you are required to host your app on your own infrastructure, you’ll then need to do a few things:

• Create the app;
• Sign it;
• Create a manifest file (the URL for which you would provide to your MDM solution);
• Host that file and the binary of the app somewhere that your users’ devices can access them;
• Maintain those files and that hosting infrastructure, the associated developer account, distribution certificate, and provisioning profile.

To distribute an in-house app, your best option is definitely MDM. Alternatively, you can distribute a link to that manifest file, which users can click to install the app. In this latter case, users must also assert that they trust the developer certificate in the Settings app; the app will be quarantined until they do so. If you deploy via MDM, the in-house app is automatically trusted by the user’s device (even if you are hosting the app yourself), and they won’t have anything special to do.

If any of those steps fail, the app will stop working; it’s a lot of moving parts. But if this is the only option that works for you, it is supported and can be handled by MDM.

Direct from the Developer

For Mac, there’s one more way to get apps on devices, and it’s the one most of us already use: Downloading directly from the developer. App Store, custom, and in-house apps represent a tiny fraction of the apps deployed to Mac; everything else is direct.

In many cases, such apps are not available in the App Store for a reason: they aren’t sandboxed or they don't meet other App Store requirements. Typically, the developer takes care of packaging the app, hosting it for downloads, and dealing with payments. As an admin, you typically have to download the app, then repackage it for distribution via MDM.

In Kandji’s case, Auto Apps allow you to distribute more than 125 non-App Store apps easily; Kandji handles the repackaging and keeping those apps updated. And Kandji Custom Apps (again, not to be confused with the custom apps described above) let admins do the repackaging themselves, which can include personalizations and scripts, and then use Kandji to deploy them to their Mac devices like any other app.

App Distribution: Choosing the Right Channel

Many times, if an organization has recognized they need an app to answer a specific business requirement, their first thought is to build it themselves. We’d encourage them to consider the alternatives first. 

Start with what's out there already. Search the App Store to see if something there can do the job for you. In many cases, you will find that there is.

If you have a specific need that can’t be answered by a public app, your next best bet is either an unlisted or a custom app. If you can't create a custom app internally, you can always contract an external developer to help. 

The primary advantage of custom apps over in-house apps is: Custom apps are vetted by Apple. The company performs the same due diligence on custom apps as App Store apps. The company reviews them to be sure they doing things like eating battery life or using unsupported private APIs. It also makes sure that the app really needs the privacy entitlements—such as access to the camera—it's requesting. Apps are inspected for the presence of malware. Even with all that scrutiny, Apple does not read all of your code or gain access to your intellectual property.

Other advantages of custom apps: They're hosted worldwide. And, because they use Apple's distribution infrastructure, they're often cheaper to deploy than their in-house counterparts.

With in-house apps, you're responsible for everything your app does. No one else is checking over your shoulder. You don’t get the advantages of Apple vetting or hosting your app. You run the risk of someone forgetting to renew your developer account (yearly), your provisioning profile (also yearly, but separate from your account renewal), and your distribution certificate every three years (which requires rolling out a new build of the app to all devices). Miss any of these, and your app won't work.

That’s not to say there aren’t arguments in favor of in-house apps—but it is worth challenging them. 

"I can’t use custom apps, because the App Store review process is too slow." Apple’s app review process isn’t perfect. But nowadays most reviews are turned around in 24 hours; it’s not uncommon for them to take just hours. 

If this is your excuse for going with an in-house app, you might want to look at the rest of your development process and see if you can tighten it up. Revised QA and QE processes could help avoid the last-minute rush and make a custom app viable.

“I need to run more than one version at a time.” Some organizations have different groups using different versions of their app. They can’t just push out a single new version—which hosting it on the App Store would require—to their entire fleet. 

You can mitigate this challenge by using your MDM solution to control when app updates are sent to your devices. You can configure that solution so your early adopter group gets updates immediately, while more mission-critical parts of your business get those updates later.

There are cases when in-house apps might make sense, primarily for legal reasons. Some organizations—including government entities—can not legally let any of their intellectual property live in Apple's App Store. Some must abide by strict export controls. 

Otherwise? You’ve got several viable alternatives through the App Store: public, unlisted, or custom. For the very large majority of use cases, those alternatives are easier to manage than in-house apps.

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.