Deploying Internal Enterprise Application for iPhone

by Craik Pyke on 09/09/09 at 7:30 pm

Deploying Internal Enterprise Application for iPhone

Craik Pyke is telecommunications architect and software developer specializing in mobile applications and an editor for iPhoneCTO.

The proliferation of the iPhone has led to a general recognition by enterprises of the iPhone’s potential as a delivery vehicle for applications. The more publicized and therefore common approach for Enterprises is to obtain a standard developer’s license and produce an application that extends their brand, increases their value proposition or simply generates increased eyeballs for their website. SalesForce.com Salesforce Mobile is a well known example of an enterprise providing mobile client access to their hosted capabilities via an iPhone application.

There is another facet to enterprise applications – the Enterprise Developer’s License. The enterprise license provides a key benefit to the IT department of a company; namely the ability to develop and deploy applications in-house, without the need to drive employees to the iTunes to gain access to the application. In-house application deployment permits an IT to develop and deploy exactly what they require, without wading through Apple’s approval processes or lead times to get into the App Store.

The process between the Enterprise Developer Program and standard Developer Program are effectively the same. Namely:

  1. Setup up the development team
  2. Obtain the iPhone development certificates
  3. Assign devices for the developments team (i.e the devices that are for development specifically)
  4. Install the target OS (3.1 by example)
  5. Create the Application ID
  6. Create and download development provisioning profiles
  7. Build and install your application

The above portion of the development process is the same for both programs. Therefore, if an Enterprise doesn’t want or is unable to resource iPhone developers in house, they can, at a minimum, contract out the development (just be sure to have your assignment of IPR ownership worked out to avoid issues with the developer later).

Distribution is, of course, where the processes vary slightly. It is in this distribution process for enterprises that I find that Apple does stumble slightly – more on that as we proceed.

When an enterprise is ready to deploy their application (not ad-hoc “Beta” test it), it’s necessary to generate an ‘Enterprise Distribution Provisioning Profile’ via the Developer Program portal. The profile is used both in building the final application version (in Xcode) and to actually install the application.

In my opinion, this is where Apple’s processes breaks down a bit. The mechanism for distributing the application (the .app bundle) and the provisioning profile (the .mobileprovision) is effectively out of scope for Apple. They don’t provide an Over-the-Air push mechanism, nor a push to iTunes mechanism. Instead, Apple defers the responsibility to the enterprise, stating in the User Guide that distribution is to occur “…using your company’s authorized software distribution mechanism.” My perspective though is that there are two problems with this approach:

  1. There’s no means to enforce/guarantee employees install the application. I’m not envisioning a big-brother monitoring and reporting application, but if you want ubiquity of the application to your mobile workforce, you’d like to make sure they have the tool actually installed. This may not be a significant issue, but it certainly is a consideration.
  2. There’s no control over where the application goes. Once the application and provisioning profile are out, they can be installed on any iPhone / iPod Touch. Apple warns in the same user guide “Please ensure to protect the distribution mechanism of this type of application as it can be installed on any Apple device if compromised.” I realize and fully support the notion of permitting employees to bring their own devices, but the inability to contain an application to a known set of devices can be a discouraging reality to enterprise IT.

Of course, I’m not discouraging Enterprise in-house distribution. I believe it is an excellent mechanism to distribute applications without the need to pass through Apple’s approval process or worry about the associated delay. I don think through that an Over-the-Air mechanism, building on the profile/policy pushes already available with the iPhone Configuration Utility.

Overall, Apple is definitely ensuring the iPhone can be successfully deployed into an enterprise environment. In this particular case, to truly compete with RIM’s BlackBerry success, Apple needs to support the same push of in-house applications that RIM has enabled to its enterprise users.

Similar Posts:

  • kpopper
    Do you think it would be possible (and indeed permitted) for a company to use the Enterprise Developer license to manually install a given application on its customers' devices?

    Say you own a business and your customers spend a lot of money with you, you might want an app that you can give them as a thank you or as a value add but that you don't want generally available on the App Store.

    I realise there are other ways to restrict access to a freely-available app but if you have the means to easily install an app manually, it would make life much easier (and the app cheaper to build).

    Thanks
  • PV
    I'm wondering the same thing as well... I haven't find an answer to this yet... have you?
    I would like to use the Enterprise Developer license to install applications on our best client devices.
  • No, I haven't found a way to do this. My proposal for this client was just to provide the app through the app store but to lock it down with a password screen. Not ideal.
  • Great article

    Do you have any ideas around IPR ownership? How do you protect a concept for an app?

    Thanks
  • Craik Pyke
    apologies - I hadn't noticed your comment... As with any outsourced development, you require a solid NDA and legal contract/agreement between your company and the developer company. You should ensure that all documentation and software is properly assigned to your company in terms of ownership - whether or not it's ever launched as "generally available". Make sure you protect yourself from agreements where IPR isn't assigned until the application is published. Also, be aware that many designers may demand a higher rate or some other compensation for immediate assignment of IPR (anecdotal note: I'm aware of an arrangement where the designer assigned IPR only after payment in full was received. The App was published to the AppStore under the designer's development certificate, not the contracting companies. This created a problem whereby the designer pulled the application from the store and withheld the documentation and source when the net-payable terms weren't satisfied. It was all worked out in the end, but it created a bit of a scary moment for the contracting company).
  • Have any opinions on Android and Symbian? Can these openOS device conexist in the enterprise. Can blackberry and iPhone for that matter?
  • Craik Pyke
    Hey Andy -

    I have some reservations about Android as it currently stands, based on 1.5 and the HTC Magic platform. You can find my thoughts here: http://iphonecto.com/2009/09/17/iphone-google-a...

    If a certain handset vendor with forthcoming android based devices were to better address the enterprise configuration side (exchange, WPA-EAP, etc) and had better battery life, I'd be very interested in trying said device out :)

    I've configured a Symbian S60r5 device for enterprise use too (specifically the Nokia 5800XM) - it certainly works out-of-the-box better than Android 1.5, but configuration was a real kick in the pants, and took a fair amount of fumbling around.

    As for co-existence - yes, I believe they can co-exist, and will. Certainly my present day-time employer permits it, and other enterprises are moving to a "bring your own phone" model. But they'll need to support a minimum capability set (not least of which is the exchange policy support, with remote wipe capability) that the users will have to accept.
blog comments powered by Disqus