Alternative solutions for in-house iPhone enterprise app distribution

I was researching this yesterday and today, and it appears that Apple has just (within the past week) removed the >500 employee requirement for enterprise development. However, I believe you will need to develop/deploy for a particular client using a development toolkit registered by the client.

So if you do work for client A and client B, both client A and B will need to sign up with Apple as business developers, at which point you can develop apps for them (as a contractor) and use their tools to build and deploy within their enterprises. I would think it would be a good idea for your company to also be registered as a business developer.

Apple does still require you to have a Dun & Bradstreet DUNS number to sign up as a Business Developer.

You can submit the app as a completely free app on the AppStore but require that the user log in and authenticate to use it. That way anyone can download it but you control who can actually use it. Apple does all the distribution for you for and you don't have to worry about Ad-Hoc deployments or IT departments.

You then build a really simple configuration management system on a web host (or platform like Google AppEngine) that manages the authentication of apps.

When a user launches the free app they are asked for a username/password/whatever. That information is sent to the web-based configuration management system and confirmed. If the app receives an acceptable confirmation from the configuration management system it unlocks itself for use by that user.

The app can either re-authenticate every time it launches (useful if you want lots of control) or it can store a key file locally indicating that it has been authenticated. If it sees the local key file when the app launches it considers itself authenticated and never checks again.

Whether you use one user account per person or one for the whole company is up to you.

This style of distribution is very useful if you want to have control of who can use the app but want the ease of deployment that the AppStore provides.

Apple has accepted many apps onto the AppStore that use this method of authenticating against a remote server (Skype is a perfect example).

If you keep track of device UDID on the configuration server you can also pre-load it to allow a certain set of devices to work.

Further, nothing I have described is iPhone specific so you can use the same configuration management system and concepts on other platforms like Android (or even desktops) if you ever port the app or build other apps needing this in the future.

Also, since the action of authenticating devices is not processor or data intensive you will likely never incur a cost if you build this on Google AppEngine as you will never go over the free quotas and you will gain the stability and scalability of Google's backend architecture.

As this particular deployment is for managing an in-house back-end system deploying it through the AppStore can seem insecure because there is proprietary information embedded in the app, in particular the information that allows it to connect to and authenticate against the back-end systems.

The solution to that is to not include this information within the app and simply have that information be part of the response that the app receives from the configuration management server. Basically the app contains the logic necessary to perform its function but without the connection information it has no ability to manage any back-end system.

If you make the app authenticate every time it launches you can change the connection information on the configuration server and the app will update to the new information without any new deployment being necessary. The user just needs to restart the app. This gives your client the flexibility to change their internal network configuration without invalidating your application code. You could also make this information manually configurable within the application but then you incur an IT cost when setting up the application on each device and if you already are going to set up a configuration management system you might as well use it.

To further secure the above solution you may want to have the configuration management system be in-house and behind the company's firewall so that regardless of who gets a hold of the app they cannot connect to the config system unless they are within the company's network.