Alternative solutions for in-house iPhone enterprise app distribution

Question

A client has asked us to develop a proprietary in-house app for managing their back-end systems. However, we are a small development company and I'm certain that their company does not have >500 employees.

Are there any alternative, yet similar, solutions to distributing this app to their company without going through the iPhone enterprise program?

(just to clarify: obviously, we would like to go through the official enterprise program but seeing how the company doesn't have >500 employees, this isn't possible).

UPDATE (27/09): It appears Apple have removed the 500 employee limit for the enterprise distribution See here. So this will probably be our route now (which is helpful because the app is approaching completion). I'll update this as we go through the process if anyone would like me to, so that others may get an idea of what the actual process is like.

Tiffie

i developed an in-house app, I try to open above link devworld.apple.com/programs/ios/enterprise/---but its not working ,anyways I just wanted to confirm that is it possible for small company (approx 200 employees) and also customer can download this in-house app without the use of app store? thank you – Comines

@Comines - it is possible for a small company to distribute an enterprise app (in fact my client has approx ~50 employees). Technically a customer could download* that app but you'd need to be very careful when it comes to distribution. Each app comes with your enterprise distribution certificate. Malicious users could extract that certificate and start signing their own app with it, which clearly isn't a desired result. – Tiffie

Answer 1

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.

Hodgson

+1 Certainly the most sane option for small to medium deployments. – Taliataliaferro

This certainly sounds like a brilliant solution, many thanks. I guess the biggest concern I have for this is the fact the app is for managing financial back end systems, might have a hard job selling this deployment method to them as they might consider it "unsafe". Another issue is we're developing the app in C# (MonoTouch) (I like / can code in Obj-C but being a .NET firm, this makes sense for the other developers to be able to contribute without learning a new language) given Apple's recent announcement, I wonder if that'll be another roadblock. – Tiffie

@Luke, I have updated the answer to respond to your concerns of this solution being "unsafe". Unfortunately I have no way to completely solve that problem but there are many ways to get closer to a "safe" solution. The solution proposed by Tobias P. may be your best option if you need to stay completely off the AppStore but look at my comment to his solution and keep that in mind. I wish I knew whether tools like MonoTouch will continue to be usable in the future. Good luck! – Hodgson

@Luke: Apple's policy is that all apps must be written in C, C++, or Objective-C, and C# is not on the approved list. Particularly if you're putting it in the App Store, they may call you on that. If you're going to write iPhone apps, you will need people competent in Objective-C and Cocoa. – Contrapose

Had a meeting yesterday and the boss certainly didn't want to go down the route of ad-hoc; the disadvantages outweighed whatever gains were to be had. He seemed to like the idea of the app store, I essentially told him what @Bryce wrote. He's meeting the client to further discuss the app itself and propose this method of distribution. For our solution I think it's certainly the way to go; also got the added perk of free advertising of the company via the app store. Many thanks for all your help, much appreciated. – Tiffie

This answer seems to be a quit old. Does it work in current Apple community? Do they accept the apps in which there is no sign-up option, only there is log-in option! – Radiocommunication

Answer 2

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.

Shivery

Answer 3

About the only real choices you have are...

• Up to 100 devices as ad-hoc distribution.
• Enterprize distribution (requires > 500 employees)
• Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
• Jail-broken.

Jail-broken may sound scary, but it's actually pretty advanced, now-a-days, and can be managed quite easily. Still, it voids your warrantee (unless you're willing to restore-to-factory and be not-honest about it ;)

Still, technically, it's an available option and can be made to work, if you're willing to plan it out.

Let us know what you decide, and the pros & cons of that method.

Hinterland

I was afraid that would be the answer; also sent an email to Apple to see if I can get anything straight from the horse's mouth but I am not holding my breath. It's a shame they restrict the enterprise plan to >500 employees really. I'm not sure how keen they'll be on jailbreaking all their phones (I perhaps should note as well that we're hoping to develop for the iPad as well - as far as I'm aware, there isn't a jailbreak for the iPad?) We're meeting the client on Monday so I'll let you know what we decide (and the reponse from Apple if I get one!) – Tiffie

Answer 4

Another obvious although not neccesarily pleasant is to submit your app to the app store as an app but can only be accessed with a client password. Assuming you can get past the aapp store process this might work for you.

Dana

Answer 5

Olie said:

About the only real choices you have are... Up to 100 devices as ad-hoc distribution. Enterprize distribution (requires > 500 employees) Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!) Jail-broken.

But to be clear (correct me if I'm wrong):

1. if you use the "Ad-hoc" distribution method, your costumers will see the app vanish after exactly 3 months.
2. only up to 100 devices can be used for testing (i.e. used in "developer mode") and moreover, the app will vanish after 3 months.

So, Apple doesn't give us any choice, are you really big (>500 employes)?? ok so you can do what you want etc otherwise... "byebye"

Moreover, forget about what "Bryce" said before, an app like the one he described would be rejected with the "limeted audience" motivation.

iOS is not for enterprise app....if you don't want to rely on some clever hackers (i.e. jailbreak)

Incivility

+1 to possible rejections due to "limited audience", might be worth a try to submit an app as outlined by Bryce but don't count on it on being accepted. – Abortion

Answer 6

Ad-hoc distribution is limited to 100 devices per app, that's true, but you can add the project n times to the apple developer center, so you can deploy it to n * 100 devices

Crasis

You will have to pay $100 per year for a new developer account for each 100 devices as Apple limits each developer account to having 100 devices it can Ad-hoc distribute to (this really is not the expensive if you are getting paid to develop the app). However, I believe (but don't have the link to prove it) that it is against Apple's policies for one developer to have multiple developer accounts for the express purpose of circumventing this limitation. – Hodgson

Answer 7

How does apple ensure that your enterprise has greater than 500 people? I'd give it a go through the enterprise program anyway...

I would not jailbreak, I would not do ad-hoc because it is limited to 100, and I wouldn't make everyone put their phones in developer mode.

For future maintainability, enterprise mode is the way to go, so see if you can navigate your way through the process without mentioning that you might not be quite 500 users.

Also, I saw your comment about developing using MonoTouch. I would talk to Apple about this before you do anything else, because given their recent policy changes I am pretty sure this will get your app denied from the App Store and the Enterprise program.

Edit: I checked the Mono web page. It seems like Apple may still be letting mono apps in, and the Mono creators insist that it is kosher, but you might be running the risk of having your future app pulled from phones at any time.

A better edit: Straight from the mono website: Enterprise MonoTouch

It is important to point out that the new iPhone Developer Agreement terms are for AppStore deployment and not the Enterprise program that allows deployment of in-house application to users in the enterprise (using the Enterprise Deployment program).

So you might be good there as long as you can get into the enterprise program.

Nevus

One of the requirements for the enterprise program is providing a DUNS number, which I know our client doesn't have either so unfortunately this isn't an avenue we can explore; thankyou anyway ! – Tiffie

Answer 8

You can completely bypass the App-Store or Enterprise Developer Program approval process, if you develop your app as pure HTML5 solution. This technology is called webapps. And they can be pretty advanced in functionality. You automatically have cross platform readiness and very easy deployment options (as webclip this can be distributed via .mobileconfig configuration files) See http://www.apple.com/webapps/whatarewebapps.html

Milo

Answer 9

There is another solution: an own app store:

http://rhomobile.com/products/rhogallery/

unfortunately only in combination with RhoHub.

Or: http://www.appcentral.com/

More info: http://www.apple.com/iphone/business/integration/mdm/ http://www.cio.com/article/638175/Emerging_Tech_Alternatives_to_Apple_App_Store_For_Enterprises?page=2&taxonomyId=3002

Backboard

Answer 10

In theory the proposed solution of publishing a free app meant for one company is not valid, since published apps in the app store should not be intended for a "limited audience" (whatever that means), according to:

http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience

Has anyone tried this with success? Any other ideas?

Royer