5 Options for Distributing Your iOS App to a Limited Audience

Imagine you’ve built an iOS app for a limited set of users. Since it requires authentication, the app is useless to the general public. Is the public App Store the only option to deploy this app without express shipping devices through the mail?

I’ve identified 5 options that you should know about.

1) The Public App Store

Distribute the app on the public App Store. Only people authorized to use the app can authenticate and use its features. Requiring a small price (such as 99 cents) will discourage casual installations.

Submitting to the public App Store requires an iOS Developer license for $99 per year.


  • Apple provides the distribution service – The App Store. It is highly available and well understood by users.
  • The App Store promotes your company on a highly visible marketplace.


  • The App Store approval process is required for initial app deployment and app updates. You may be required to make changes to the app. The approval process can take a few days or a few weeks.
  • The App Store provides information about your app to competitors including a description of the app’s features, screenshots and an indication when the app is updated.
  • If you charge a price for the app, 30% of the revenue goes to Apple.


2) iOS Developer Enterprise Program

The iOS Enterprise Distribution program allows a company to distribute their own “in-house” apps directly. It is intended for employees of the licensee company only and that licensee must be a company or organization with a DUNS number. The cost is $299 per year for this license compared to $99 per year for the iOS Developer License. A given device can have apps installed from only one iOS Enterprise License at a time.

*Note: The following is an excerpt from the iOS Enterprise Distribution License Agreement

“Internal Use Applications developed under this Agreement may be deployed on Deployment Devices in two ways: (1) deployment for internal use by Employees, and (2) deployment for use by Customers either on Your physical premises or under the direct supervision and physical control of Your Employees in other locations, subject to Apple’s right to review and approve such deployment as set forth herein.”


  • The App Store approval process is not required.
  • The general public cannot see a listing for your app, purchase or install it. It is not on the App Store.


  • The Enterprise program is intended for employees and contractors of the licensee only.
  • The licensee is responsible for distributing and updating the app. This can be done manually by email, making the app available on an Intranet site, through a Mobile Device Management System (MDM), etc.
  • The cost is $299 per year for the Enterprise Developer Account compared to $99 per year for the iOS Developer Account.

*Note: The Enterprise program does not enable you to deploy apps to the Public App Store. For that you need to be enrolled in the standard iOS Developer Program.


3) Custom B2B Apps Program

Apple has programs for volume purchasing and custom B2B apps. These programs operate from the online Business Store. The Volume Purchasing Program allows businesses to buy apps from the public App Store in bulk. Custom B2B Apps extend the Volume Purchase Program for custom B2B apps built by third-party developers. The third-party developer determines which Volume Purchase customer(s) can purchase a given app. Such apps are not available on the public App Store but only through the Business Store.


  • More convenient for larger distributions. Each individual installation does not require a user to make a purchase through the public app store and expense the cost. Instead, users are given a coupon that they can use to install the app.
  • Apple provides the distribution service – the Business Store. This provides some features of an MDM.
  • The general public cannot see the listing, purchase or install the app.


  • Requires App Store approval process for initial app and updates.
  • If you charge a price for the app, 30% of the revenue goes to Apple.
  • B2B apps are only available to businesses enrolled in the Volume Purchase Program. The Volume Purchase Program is limited to 10 countries as of May, 2013: Australia, Canada, France, Germany, Italy, Japan, New Zealand, Spain, United Kingdom, and United States

*Note: An iOS Developer License is required to use the Custom B2B Apps Program. Limiting an app to the B2B App Store is an option when submitting to the Public App Store.


4) Ad Hoc Distribution (intended for Testing)

Ad Hoc Distribution allows you to distribute apps to up to 100 iOS devices for testing. You must register these devices manually by their ID. Devices can be removed/replaced once each membership year). Ad Hoc Distribution is a feature of both the iOS Developer Program and the iOS Developer Enterprise Program. This may be all that is needed for a prototype or trade show.


  • The App Store approval process is not required.
  • The general public cannot see the listing, purchase or install the app.
  • Over-the-air installation from a hyperlink (hosted on your web server or on an iOS Beta Testing Service *mentioned next) or by emailing to a computer with iTunes installed (and then installing to the device).


  • Limited to 100 devices (devices can be removed/replaced once each membership year).
  • The UDID (Unique Device IDentifier ) of each device must be associated with your provisioning profile. This is a manual process.
  • Your team must manage deployments and updates.
  • The related developer provisioning profile expires in one year. This means that the app will run on a given device for a maximum of one year. When the Developer Provisioning profile expires the app will need to be rebuilt with a new provisioning profile.


5)  iOS Beta Testing Service: TestFlight

TestFlight is a free over-the-air platform used to distribute beta and internal iOS applications to team members. Developers can manage testing and receive feedback from their team with TestFlight’s Dashboard.

TestFlight makes use of your iOS Enterprise License or Developer License to create Enterprise and Ad Hoc provisioned apps.


  • The same Pro’s as #2 iOS Developer Enterprise Program or #4 Ad Hoc Distribution depending on which iOS license you use.
  • Distribution and feedback is managed with a free, cloud based service.


  • The same Con’s as #2 iOS Developer Enterprise Program or #4 Ad Hoc Distribution depending on which license you use minus the Con about managing deployments and updates.


Other Testing Tools and Services

  • Hockey App: Beta and release deployment of Mac OS X , iOS (beta only) and Android.
  • HockeyKit: Open source project for hosting beta versions on your own PHP5 server.
  • Apphance: Deployment on iOS, Android, Windows Phone, Nook and Kindle.



  1. Great article Dan! I wasn’t aware of the B2B distribution mode. Good to know!

  2. Good resourceful info, all in one place. Liked the way you have brought about the pros and cons for different app distribution methodologies. Here is a link to an article that provides more insight on how MDM can help in app distribution. http://www.maas360.com/maasters/blog/newsonthemove/smaller-world-apple-app-volume-purchase-program/

  3. Thank you for the plain-talk style of presenting the deployment options. I have been researching the options for months and this is most helpful.

  4. Regarding #2 (iOS Developer Enterprise Program ‘In-house’ apps):

    I’m an ISV developing an iOS app. I have the following needs:

    1) There is an on-premises server component to our app (which incidentally makes the app worthless to the general public). Over time, we have a range of server versions in the field. Since the App Store (including B2B) allows me to only distribute the most recent version of my iOS app, then the app must be backward compatible with every past version of my server. I can’t always just tell the customer “Hey, just upgrade your server to latest version” because of the slow-moving nature of some of my customer IT teams. Supporting every combination of client version and server version will increase my testing costs significantly, so I’d like to control what version of my iOS app is used by a given customer.

    2) We sometimes have the need to hotfix our app when severe bugs slip by our QA process; it’s part of our SLA agreement with our customers. Waiting the 7-9 days for review would be very painful in some cases where customer work is blocked, so I’d like to be able to distribute outside the App Store.

    Given the above, your excerpt from the enterprise program agreement is critical for me, and I don’t meet its criteria, since my customer’s employees are neither on my premises nor within my physical control.

    I’m therefore trying to assess this approach:

    Have our customers purchase the iOS Developer Enterprise Program membership and distribute my app internally as an in-house app, even though I wrote it. To be able to do this, I’m told that I would have to sign our app with the customer’s provisioning file, which I can do. I’ve already purchased the Enterprise Program membership so it’s not about trying to save $300.

    Is this compliant with the agreement and a reasonably well-travelled route for ISVs in my situation?

    • Great questions Ken!

      I will tell you my thoughts but I am no authority on Apple licensing.

      With respect to question #1, if you used the B2B option, you could have a separate distribution of the app for each client even if you were sharing a common code base.

      I don’t see why you could not have a client or clients use their own Enterprise license to manager their own distribution of an app you create for them. I am sure Apple doesn’t expect each Enterprise to develop their own iOS apps internally for Enterprise Distribution. The constraints on the Enterprise license are to keep someone from attempting to create their own app store. I have been told that a given device can have apps from only one Enterprise license installed at a time. This would naturally limit abuse of the Enterprise license.

      The distinction in your case is that you are customizing a common application base to each client. I am not sure if it matters to Apple if the Enterprise app was built custom vs customized.

    • @Ken : We have ISV customers using MAM / enterprise App store with their customer certificate for distributing in house, so I assume that it is compliant with Apple agreement.

  5. Regarding this comment:

    4) Ad Hoc Distribution (for Testing)

    The App Store approval process is not required.
    The general public cannot see the listing, purchase or install the app.
    **Over-the-air installation from a hyperlink**

    I didn’t see this as an option on Apple’s website. Do you have a source for this?

  6. Hi,
    Thanks for a great guide. We are going publish enterprise apps and I would to know where did you find this text blow here?
    Best regards

    Internal Use Applications developed under this Agreement may be deployed on Deployment Devices in two ways: (1) deployment for internal use by Employees, and (2) deployment for use by Customers either on Your physical premises or under the direct supervision and physical control of Your Employees in other locations, subject to Apple’s right to review and approve such deployment as set forth herein.”

  7. In the section on the Enterprise license, you state: “A given device can have apps installed from only one iOS Enterprise License at a time.”

    How is this enforced? Is it just part of the agreement, or does the device actually reject installation of a 2nd Enterprise-licensed app after the first one?

    • I have not been able to test this myself. What I’ve heard from people who manage internal enterprise app stores is that the device will not allow you to install apps from two different enterprise provisioning accounts.

  8. J Cangelosi says:

    I work for a large vehicle manufacturer and we were hoping to leverage the B2B store for distributing apps to our externally franchised dealers for their exclusive use. However, requiring each location (up 1000 individual entities) to have VPP accounts is a show stopper.

    Any insight on how to make the B2B store work for this model of an externally franchised distribution network? I can imagine the same question would apply to Insurance companies who generally have independent agent networks.


    • That’s a great question!

      I do not have access to the Volume Purchase Agreement legal contract yet. I referred to the “App Store Volume Purchase for Business” guide (pdf) and it says under the “Custom B2B features” Section: “Features targeted to a limited audience, such as a business partner, dealer, or franchise”.

      Clearly the B2B app store is intended for your scenario. The question becomes” who can the Volume Purchaser distribute B2B apps to? Must the recipients be employees? I do not know the answer to that but if/when I do, I will post it. Please do the same.

      From my experience, a relationship of recipients to the Volume Purchase Account is not enforced by technology. One Volume purchasing agent could distribute apps to whoever they want. Once an app recipient installs a B2B app, it is independent from the Volume Purchaser (for example, the Volume purchaser cannot revoke the app from any user).

      That said, you would want to know for certain with a large installation. Apple may have an automated watch for certain B2B app installation patterns to alert it to violations of the program. Obviously you’re intentions are to build a business app not to do anything malicious.

      Keep in mind that registering for the Volume Purchase Program is free for businesses (who must supply a D-U-N-S number). Would that not work in your scenario because it is an added step for users or for some other reason?

      • Ala Eddine says:

        Hi Dan,

        Great article!

        Regarding #2 iOS Developer Enterprise Program, I think that you also have to renew the provisioning profile for your apps every year so they can continue to be used (yes the app “expires”). This is similar to #4 except you don’t have to rebuild the app, you just need to deploy the new provisioning profile (At least this is what I understood from the Apple documentation here : https://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html).

        I’m also wondering if it is possible for a company to distribute a Custom B2B app to itself. This would be used instead of the iOS Enterprise Program and Pay 300$ each year, and the app would not expire!


        Ala Eddine

        • In response to a company distributing a Custom B2B app to itself: I tried this in early 2012 and the app was rejected because the company distributing the B2B app cannot be the same as the company eligible to buy the app. I had only tried this because I wanted to test the distribution process. I used the same apple ID for distribution and as a buyer (registered in the Volume Purchase Program).

          Technically, if you use a different apple ID and company identification for the distribution of the app and for the Volume Purchase Program (eligible to buy the app) you would be able to control distribution of apps through the B2B program to your company. I cannot say whether this would violate the license agreement or not.

  9. I understand that we can use enterprise distribution profile to distribute apps.
    Here are my doubts:

    Is there any limitation in number of devices on which the app ( just like 100 for adhoc) can be installed if I am using enterprise distribution profile?

    Also is there any time limitation for apps distributed using enterprise distribution ( I suspect a 1 yr limitation…)?

    • You are right, your certificate (whatever) is only valid 1 year.
      With Ad-Hoc, you can only distribute to 100 users.
      With In House, you are committed to distribute within your company.

  10. Enterprise program has expiring problems too. Doesn’t it?
    Every solution has major drawbacks. B2B through VPP sounds interesting, but the slow revision process makes it an unfeasible solution for most businesses.

  11. “Apple has been known not to approve apps that start by asking for a user ID and password.” Is there an offical statement from apple for this. I can’t find anything in the guidlines. Thanks

    • Not really. But they will reject your app if you ask the user to register with an email.

      • Is this “across the board”? We have built an app for our e-auction website and we decided to add a registration option. The problem is that the registration option requires an email address. To bid on an auction a user must have a user account on our site, which requires the email address…

  12. Whatever tool you’ll end up using you’ll need to have a way for your testers to send feedback easily, and for you to get more detailed user feedback, more than just the comment.

    Instabug (http://instabug.io) does exactly this, it allows users to send in-app feedback without interrupting their experience while using the app.

    Here’s a promocode for you to signup with: rnd4250.

  13. I see that you updated the B2B part to reflect that there is no longer a minimum price for apps distributed this way. However, I see the original bullet point also indicated that Apple charged a 30% fee for B2B. When they removed the minimum price, did they also remove the fee? Or does the 30% fee still apply to B2B? If the latter, perhaps the fee should be included as it’s own bullet point in the Cons section.

    • Thanks Mike! Good catch. A 30% fee does apply to the B2B program if the app has a price. I took your suggestion and updated the “Con” section under “3) Custom B2B Apps Program” to reflect that.

  14. Hi,

    Thanks for this good article.
    There is an another limitation for Custom B2B Apps Program, the VPP program is limited to 10 countries (cf http://www.apple.com/business/vpp/) !

  15. Hi,
    Thanks for this nice article. And I know how it is hard to explain the complexity of App distribution.

    However, I would have presented it a bit differently :
    – First, you have private or enterprise App Store, like TestFlight, Appaloosa (which I am part of the team) or others Mobile Application Management solution which help in simplify distribution during development process (with Ad Hoc or in House certificate) and then for private distribution (with in House certificate)

    – Second, you need the public app store (for distributing publicly) or a MAM solution (MDM is more focus on the device even if they begin to implement MAM features.

    Here is a nice infographic we made to explain how to distribute an app :

    Hope it can help 😉


  16. Apple needs another solution here or to modify the ad-hoc limit of 100 device UDIDs per year.

  17. Good info here, thanks. I’m developing a comprehensive B2B app that should sell for about $1000. We don’t want to pay Apple $300/unit (I WOULD pay, say, $100 tops for distribution through an online store). Doesn’t it make more sense for me to pay for a dedicated tablet (i.e. a Nexus7) and ship my app WITH hardware?

    • I don’t think it makes sense to ship the app ad-hoc with the hardware. You would be in violation of the license agreement (and at risk of being detected and revoked) and I think you’d run into inconvenience problems with updates and provisioning.

      It sounds like the B2B program would be a good fit. It is unclear to me if Apple expects you to charge all your development fees through the B2B app store. What is to stop a company hiring you to build an app for them and then publishing it to the B2B app store with a price of Free. I am not sure if this breaks the agreement and am not advising you to do this – just wondering.

  18. Many thanks for this amazing article. I have developed an app for one of my customers, the largest consumer union in Europe. The app allows the paying members of Euroconsumers to compare and choose products (smartphones, TVs, computers, etc.). Euroconsumers (the client) would like to make the app available to all users, members and non members. Members can use their web credentials to login and use the app. Non members can create an account for free and use the app for a limited period of time. In case they’re intesrested, they can call Euroconsumers and become members.

    The app was rejected by the reviewers with the following explainations
    “Your app does not comply with:
    11.13: Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected

    We understand that your application both members of Euroconsumers and the general public. However, we found that your app is tied to your website where users can purchase a subscription. Since your app provides users a paid option aside from the free account option, it is not appropriate to allow for user registration. As such, it would be appropriate to remove the account creation mechanism from your app. Please see the attached screenshot for details.
    Therefore, your app will not be posted to the App Store at this time.”

    Do you have any suggestions for me ?

    Many many thanks again.

    • This reminds me of the precedent set when Amazon’s Kindle app and Sony’s reader app were rejected by Apple. At first it appeared that Apple would require companies like Apple and Sony to give 30% of sales to Apple. Apple later clarified that it was ok to use an app to access content that the user paid for outside of the app. However, the app could not enable, link to or mention an outside payment mechanism other than Apple’s.

      In your case it sounds like Apple is viewing registration as a component of an outside payment mechanism. I think you will have to remove the registration feature of the app and let users realize they must go to your website to register. This is not the ideal user experience but it is one that all iOS apps must follow. Hopefully people are accustomed to it.

      (I would assume you’ve done the following but) I would suggest you do things like…
      – Make sure your website is easy to find through search engines and by an easy to read and spell domain name(s)
      – Make sure your website’s home page makes it obvious how to register.
      – Have the website mention the app(s) and provide links to the app store screen or the installed app itself if possible (and allowed by Apple).

  19. Hey there, I am an iOS developer and my client doesn’t want to purchase the Enterprise program because of the extra cost neither the adhoc distribution since its too much hassle to gather everyones UDIDs. So we are left with option #1 which is distribution to AppStore. The only thing I’m worried about, would Apple approved an app which asks for authentication or activation code before the app is usable? Can anyone share their experience and thought in this?

    Thank you in advance and this is really a great article!

    • Why not the B2B app store? For that you use the same mechanism to publish the app to the app store. When submitting the app you check the B2B option which requires you to specify countries and companies that can see and purchase your app. The customer companies must be actual companies (in the US that means the company has a D-U-N-S number and is located in the United States) and be enrolled in the Volume Purchase Program. However that program is free.

      One use of the Volume Purchase Program is for a company to buy apps in bulk. However another use is to buy B2B apps. The name “Volume Purchase Program” is confusing if a company only intends to buy B2B apps.

      Reasons why you couldn’t use the B2B program include: your customer cannot join the Volume purchase program because they are not a formal business or they are not willing to join the free Volume Purchase Program for some reason.

      In the past I’ve read or heard stories about Apple not approving apps if they presented a login screen at startup and provided no functionality without an account. I understood that you simply needed to provide an information screen that talked about what the app does. However, there are many examples of apps that open with a required login sceen in the App Store. I am currently working for a client with an app in the App Store which starts with a required login sceen.

      • Hi Dan,

        I believe this relates pretty closely to my needs and the name “Volume Purchase Program” is definitely confusing! The documentation is also pretty difficult to understand. In my case I have a small start-up where one app will be available to the general public, but the other app only available to the service providers. Picture Uber drivers. Would the VPP be the proper channel to do this? Can I register my company for the biz side of the volume purchase program with the same DUNS that I use to develop the app?

        Thanks so much!


  20. Can a US company distribute apps purchased through the Custom B2B Apps option to employees in companies outside of the US. (And specifically to customers in countries not included in the B2B program?)

    • As of writing this reply, the B2B program is available in: Australia, Canada, France, Germany, Italy, Japan, New Zealand, Spain, United Kingdom, and the United States. (source page). You can not use the B2B program to distribute apps to the App Store of a country not in that list.

      The B2B App Store appears to me not as a separate App Store (as its name suggests) but as a filter within the standard App Store. When you post an App on the “B2B App Store” you are applying a filter that says “only users associated with a given company or set of companies may see and purchase this app”. When Apple says the B2B program is only available in certain countries, that means this filter is only enabled for those App Stores. There is no way around it as users accessing the App Stores that don’t support B2B would have no mechanism to see a B2B app.

  21. Great article! Dan, do you know of any way to accomplish the following?

    Company A creates an iOS app for interfacing with its cloud product (subscription service). Company B purchases cloud product. Company A gives Company B a customized (branded) version of the iOS app and Company B uses its own Enterprise Developer Account and MDM/MAM/whatever to distribute app to its own employees.

    Requirement: Company B cannot read the Objective-C code used to write the app.

    Considering that In-House deployment requires *building* an app with XCode and the company’s enterprise provisioning profile… is there any way to protect the code? Thanks!

    • Thank you Nathan!

      Company A can sign the app with a provisioning profile provided by Company B from their Enterprise Developer Account. Company A delivers the signed app to Company B for distribution internally without giving access to the source code.

      It’s not my understanding that Company B must have access to the source code (someone please correct me if I’m wrong). Company B has hired company A to create an app for them which is an expected and common scenario.

      The Enterprise agreement does state the following. The text in parenthesis suggests your scenario…

      You will not provide or transfer Apple-issued digital certificates or Provisioning Profiles provided under this Program to any third party (except for a third party who is developing an Internal Use Application for You);

  22. Hi. Great post 🙂

    I have a question. What about a public app with login? I mean only the employees of my company will be able to login, is that ok with Apple. Isn’t a better way to distribute? if you’re a small company or startup maybe is worthless to pay $300 per year.

    • If you are creating an app that only your employees will be able to use then the Enterprise Developer Programs seems like a good fit. The cost is $300 per year instead of $100 per year for the standard Developer Program which allows publishing to the public App Store. One benefit (of the Enterprise Program) that might help justify the extra $200/year is that with the Enterprise program you do not need to go through Apple’s app approval process. The approval process will add a delay to your app deployments while waiting for approval not to mention time spent submitting the app for approval and possibly making changes because of that.

      Both the Developer program and the Enterprise Developer Program allow for “Ad-Hoc” deployments. They are intended for testing and can only be installed on devices you register with your account. You are limited to 100 devices per year and can change each of those device slots 1 time per year. If you had a very small company, you might be able to get away with just using Ad-Hoc deployments until you find a need for a better way to deploy. I am not sure how long an app will work when deployed this way, it may be limited to 3-4 months so take that into consideration.

      • Hi. Thank you very much for your answer. We’ve delay the app development. But with your sentence: “is that with the Enterprise program you do not need to go through Apple’s app approval process” We know now which one we are going to choose. I didn’t read this before, and with that, enterprise program is totally worth it.

  23. Stuart Boyd says:

    I can’t say enough how appreciative i am of this post and comments. Its first class and the best i can find on Apple B2B. I’d love your help with these questions:

    Ive developed an app and have a iOS developer account.

    My company wants to buy the app and pay me in a single payment, then distribute it to their members for FREE through the B2B App Store via VPP
    – But they want to charge their members a yearly subscription fee – managed and maintained by them and outside of an Apple in-app subscription method for their members to have access to the app

    Is this possible, or legal in Apple agreement terms?

    Can they send redemption codes to be redeemed through in the normal App store for this app, as their members will not be in the VPP?

    Do i need to submit the app as a developer, and for them to receive the app as a company in the VPP? Or, is there a faster method?

    Thanks very much!


  1. […] In this post I will respond to a few questions about the iOS Developer Enterprise Program in reaction to my blog post 5 Options for Distributing Your iOS App to a Limited Audience (Legally). […]

  2. […] closed application distribution mechanism (may be legally circumvented in some cases) […]

  3. […] In addition, enterprise apps (those written for private distribution to a company’s employees, contractors, vendors or customers) are a bit problematic under this model, since a company is unlikely to seek approval from an OS vendor for its internal apps. Nor, in fact, do most companies want their internal apps available (for any price) on a public market. The two examples of this model do have exceptions in place to allow for this, but both are (at a minimum) cumbersome and awkward. […]