Post by Jack HarrisWhat 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.
— F