Re: iOS Developer Enterprise Program

On 19 Aug 2012, at 6:46 AM, Jack Harris <[email protected]> =
wrote:

> What I am interested in learning about, for the moment, is the =
distribution
> of in-house apps. Specifically, what procedures do you follow to vet =
the
> apps that go into your in-house app store? Are there any good, public,
> resources out there that discuss this topic as to what tests / =
procedures
> to follow to make sure an app being placed in the App Store, for =
example,
> doesn't use any private APIs, does not send data when it also claims =
it
> won't, etc...?

Forget the concept of "app store" in Enterprise deployment. There is =
none. It's not much different from ad-hoc (beta) distribution: You put =
the .ipa (application) and .mobileprovision files behind a password wall =
restricted to your organization, and let users download them.

Users can drop the files into iTunes and sync, but it's preferred that =
you put the two, plus a manifest file that Xcode will generate for you, =
on your server, and distribute the manifest's URL by email or on a Web =
page. If an iOS device follows the link, the app will install =
over-the-air.

Review is up to you. I've never thought to attempt Xcode's validation =
feature with an in-house app, but what I've seen suggests that it works =
only for apps that are in the process of release to the App Store.

The terms of the Enterprise program require you to follow the same =
guidelines as for the commercial App Store, including using only =
supported API, but my guess (no one can guarantee) is that there's no =
enforcement unless you catch Apple's attention for some other reason, =
like distributing outside your organization.

The compiler will warn you if you use unsupported API, and obviously if =
you write prototypes to silence the warnings, you'll know, so you're =
getting "reviewed" all the time. It's bad practice whether you get into =
trouble with Apple or not: (1) Apple can pull the API out from under =
you, and unlike with the App Store, the app will have been committed to =
production for months. (2) You'll have blocked your company from =
monetizing its investment in the app. Either might be expensive to =
correct.

Abusing your users' privacy is a good way to harm employee retention, =
plausible cause for a lawsuit, and possibly a crime. Your company could =
fire you for subjecting it to such liability. (Even if it encouraged you =
to do so; it might need a scapegoat. Get any such encouragement in =
writing, along with your warning of the consequences.) I'm being dire in =
my warnings, but take away the point that this is a _very_ serious =
matter.

If you notify your people that anything they do with your app belongs to =
the company, working for it would still suck, but it'd probably be =
covered.

The university I work for has a strict policy of doing security and =
privacy reviews of its apps, in-house or published. (In addition to =
general laws, we're subject to academic-privacy statutes.) We have a =
template for privacy notices, which the lawyers and I review and amend =
to suit the app.

	=97 F