3 Replies Latest reply: Dec 9, 2012 10:52 AM by Llessur999
Hansoid Level 1 Level 1 (0 points)

Hi everybody (Hi Dr. Nick!),


     We are finally getting to add an iOS application as part of our product suite for one of our market verticals.


This iOS application isn't sold, and isn't marketed, and isn't intended for anyone other than our existing enterprise software customers to make use of so I am asking what the Apple preferred deployment model is for this type of thing.


The Apple store is a very undesirable deployment model for us - we don't want marketing, we don't need someone else hosting, the application itself is free, so we've zero desire to have to submit changes/patches/fixes for each application when each corporation will have its own branded application and each application would need to be re-approved by Apple before it could be rolled out, et ceter...


I looked into the Enterprise developer program and the deployment model is perfect for us, our clients have already existing online account services with us - so rolling out the App via a web server would be trivial for us; HOWEVER, it appears that this methodology is only meant for companies to roll out apps internally to their own employees.


Is that right?  Sometimes Apple is very touchy about things and sometimes not - I don't want to use the Enterprise program in a way that Apple will be unhappy with.


Is there some middle ground?  Some way to privately provide iOS applications to companies?





  • HyperNova Software Level 6 Level 6 (8,430 points)

    There is no middle ground at this time.


    You'll have to deploy your app using the app store. 

  • Hansoid Level 1 Level 1 (0 points)

    Well, there is sort of a middle ground actually, it's the volume purchase program - but that's not a very good fit either in this case.


    We'll figure something out.  Maybe we'll use HTML5 (although that's limiting for the things we want to do...)

  • Llessur999 Level 4 Level 4 (1,190 points)

    If the application branding is labels, graphics, and whether specific features are enabled/disabled, consider a single app that dynamically brands itself after the user registers. The user probably needs to supply a server URL, username, and password to connect to your product suite, at this point you know what customer branding to configure.  You could download a configuration file specific to that customer.


    If your product suite is a commercial-off-the-shelf product with a single code baseline that supports multiple customers, there is a good bet the server components already follow this design pattern themselves.