Chapter 19 n Deploying Applications Over the Air 3 many smaller organizations for internal applications. As Apple loosened the restrictions around enterprise accounts, the need to jump through the additional hoops of registering each device for Ad Hoc app deployment became unnecessary for most organizations looking to facilitate deployment of internal apps. In addition to the 100-device restriction, the biggest pain about the Ad Hoc deployment model is that the Unique Device IDentifi er (UDID) must be registered with Apple through the developer portal in order to generate the provisioning profi le that is used to “sign” the application bundle. This means that anytime you want to deploy an application to a new device through the Ad Hoc deployment model, you have to retrieve the device’s UDID, submit it to Apple via the developer portal, and generate a new provisioning profi le. This can add a lot of overhead to what is otherwise a very simple app deployment process. Enterprise For in-house applications, the Enterprise deployment model is likely the way to go. In order to do this, you must have an iOS enterprise developer account. (Organizations can and often do have an enterprise developer account in addition to a standard iOS developer account.) This account costs $399 a year and requires a legal contact with whom Apple can communicate. When dealing with the legal departments of many large organizations, this process can take weeks or even months, so don’t procrastinate in starting the procurement process of your enterprise development account from Apple. Up until late 2010, Apple had a restriction for enterprise accounts that required the organization to have a minimum of 500 employees. Since the only other alternative for companies with fewer than 500 employees was to use Ad Hoc deployment, which was limited to 100 devices, there were signifi cant barriers to iOS in-house app development and adoption for many mid-sized organizations. In late 2010, though, Apple quietly lifted this restriction for 500 employees and now allows companies of all sizes to get an enterprise developer account. Unlike the Ad Hoc deployment model, the Enterprise deployment model does not require that each device be registered with Apple, as the provisioning profi le can be used by devices across the organization and is not linked to specifi c devices. This was one of the reasons Apple previously had so many restrictions on getting an enterprise developer account; it didn’t want nonenterprise developers using it as a way to bypass Apple’s approval process for the App Store. As a precaution, Apple created a mechanism whereby the distribution certifi cate is automatically validated with an Apple server (ocsp.apple.com) the fi rst time the application is run. This response is cached for a few days, but is regularly queried over time so that if Apple determines that the iOS enterprise developer account is being abused and the terms of service breached, it can remotely kill all apps built and deployed using the account. Copyrighted Material. Not for Redistibution. Copyright © 2011, John Wiley and Sons.  | iPad in the Enterprise - Developing and Deploying Business Applications Page 4 | Apperian
Chapter 19 n Deploying Applications Over the Air 3 many smaller organizations for internal applications. As Apple loosened the restrictions around enterprise accounts, the need to jump through the additional hoops of registering each device for Ad Hoc app deployment became unnecessary for most organizations looking to facilitate deployment of internal apps. In addition to the 100-device restriction, the biggest pain about the Ad Hoc deployment model is that the Unique Device IDentifi er (UDID) must be registered with Apple through the developer portal in order to generate the provisioning profi le that is used to “sign” the application bundle. This means that anytime you want to deploy an application to a new device through the Ad Hoc deployment model, you have to retrieve the device’s UDID, submit it to Apple via the developer portal, and generate a new provisioning profi le. This can add a lot of overhead to what is otherwise a very simple app deployment process. Enterprise For in-house applications, the Enterprise deployment model is likely the way to go. In order to do this, you must have an iOS enterprise developer account. (Organizations can and often do have an enterprise developer account in addition to a standard iOS developer account.) This account costs $399 a year and requires a legal contact with whom Apple can communicate. When dealing with the legal departments of many large organizations, this process can take weeks or even months, so don’t procrastinate in starting the procurement process of your enterprise development account from Apple. Up until late 2010, Apple had a restriction for enterprise accounts that required the organization to have a minimum of 500 employees. Since the only other alternative for companies with fewer than 500 employees was to use Ad Hoc deployment, which was limited to 100 devices, there were signifi cant barriers to iOS in-house app development and adoption for many mid-sized organizations. In late 2010, though, Apple quietly lifted this restriction for 500 employees and now allows companies of all sizes to get an enterprise developer account. Unlike the Ad Hoc deployment model, the Enterprise deployment model does not require that each device be registered with Apple, as the provisioning profi le can be used by devices across the organization and is not linked to specifi c devices. This was one of the reasons Apple previously had so many restrictions on getting an enterprise developer account; it didn’t want nonenterprise developers using it as a way to bypass Apple’s approval process for the App Store. As a precaution, Apple created a mechanism whereby the distribution certifi cate is automatically validated with an Apple server (ocsp.apple.com) the fi rst time the application is run. This response is cached for a few days, but is regularly queried over time so that if Apple determines that the iOS enterprise developer account is being abused and the terms of service breached, it can remotely kill all apps built and deployed using the account. Copyrighted Material. Not for Redistibution. Copyright © 2011, John Wiley and Sons.