Why App distribution policy could be bad for iPad

by: dermdaly

I see lots of people thinking of great ideas for the iPad. I agree with pretty much all of them. Anywhere where there’s a person carrying a handheld device, or indeed a notepad an pen, could be a potential application. Here’s a few examples

  • Waiter taking orders at a table
  • UPS Delivery guy
  • Gas man coming to take a reading
  • Charity worker – getting sign-ups but also using the multimedia capabilities to show where the donations are going to good work

etc. etc.

Right now, there are three ways to distribute iPhone apps:

  1. The App Store – This is designed for general purpose apps that anyone may want to use
  2. Enterprise Distribution – This is designed for “in house” only apps. This is where a company wants to supply apps for their staff use only, and not put them on the app store.
  3. Ad Hoc Distribution – This is where a developer can distribute the apps privately to a group of people. It is primarily aimed at developers who want to get real-world feedback before really releasing the app through 1 or 2 above

When we consider that some of the app ideas (e.g. the waiter concept) is really an “in house” app. But each of the distribution mechanisms has its drawbacks:

  • You may not want to put it in the app store, because it only works with your restaurant management system.
  • You’ll not qualify for Enterprise distribution, because Apple restricts this to companies of 500 employees or more
  • You could use ad-hoc, but this does take a fair bit of management for the developer. The developer needs to know each and every device id that the app will be installed on (and has a limit of 100 slots per year; which cannot be re-used during the year).

None of these are insurmountable, but they are niggles. Basically, there isn’t a simple way to distribute “private” apps. This is by design; It is a commercial decision by Apple. If there was a way, people would use it to bypass the app store (to avoid the apple cut), so its unlikely to change.

One thing it could lead to is an explosion of “new” software as a service offerings. Consider the “menu ordering” SAAS system; The restaurant signs up online, and enters their menu details. The Menu Ordering App is sold through the app store, and the restaurant simply enters their restaurant id and password when they use the app for the first time. This could work, but its a big education job to explain SAAS to restaurant owners.

I think all of those who want to put iPads into their businesses will find the distribution options confusing and consider it a hinderance.

That’s a challenge for us developers.

You’re reading the tapadoo blog. Did you know that as well as publishing our own applications, we offer iPhone development services and consultancy? If you have an idea, project or something you think we can help you with, please get in touch through our contact page.

You May Also Like

We built a product in a lockdown

At the start of the lockdown, around March last year, I have to admit a case of the jitters. I was prospecting on five different projects. Some with existing clients, some with new clients. Our order book was good - but we always have to have an eye on up coming...

read more
The Rise of the Super App

The Rise of the Super App

Imagine being able to chat with your friend through instant messaging, then book dinner, a movie or a gig and pay for everything all from one single app. That’s the power of a super app.  Mobile users worldwide have dedicated apps for specific tasks. This is not...

read more


  1. Ian Robinson

    If each ad hoc end user had their own Apple Developer account for $99, would that give them 100 devices ID slots to use each year? The developer could manage it for them. So restaurant with 10 iPads could use ad hoc distribution for theirs. If the developer worked with another restaurant they could have their own account for their device slots etc. I think some devs we know do this now.


  2. dermdaly

    Hi Ian,
    thanks for your comment. Like I mentioned, none of these are insurmountable. I do believe that to the uninitiated (i.e. business people rather than developers), it will appear to be unreasonable. This is the challenge to us.

  3. Andrew Betlehem

    I totally agree. I’ve been looking into ways to distribute custom apps to potential customers and as you say, there really isn’t a nice way to do it.
    We’ll have to use Adhoc distribution, and just keep adding new Apple Developer accounts. Not sure if there’s a limit to how many developer accounts you can have though.

    It really means that you can’t use iPhone/iPads to develop small scale apps for specific clients very easily. So compared to writing Java or VB apps, it’s really hard to distribute them.

    Maybe, we’ll just have to employ 490 extra staff to get our enterprise licence.

  4. Mike Van Alstine

    You know,

    I really want to like Apple, I do. But with Monopolistic polices that make it impossible to practically distribute applications to small-medium sized niche businesses, they will keep losing the business clients. This is one case where Apple needs to take a lesson from Microsoft, let everyone distribute software that they write for your platform freely.

  5. Douglas Gintz

    Informative article. Struggling with the same thing myself. Throw into the mix the variety of smart devices & platforms that need to be deployed to and its hard to see a clear strategy. Still looking at frameworks like Sencha and possibly leaving apps browser-based when possible. This approach too has drawbacks, and is definitely not as sexy. But then again, let’s not forget that part of the Web 2.0 revolution was an effort to move off individual desktops w/ their own environmental restrictions, and to a single, easily maintainable, source. Feels like we’re heading in the wrong direction at the moment for the benefit of the the device makers looking at apps as a way to add value. It’ll will be interesting to see what happens over the next 12 months.


Submit a Comment

Your email address will not be published. Required fields are marked *