Re: iOS Developer Enterprise Program

On Sun, Aug 19, 2012 at 1:42 PM, Fritz Anderson <[email protected]>wrote:

> 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.
>

Ah. Interesting. I wasn't sure if there would be a similar experience for
the user or not.


>
>
> 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.
>

Yes, I understand that the review is up to me, but what I am wondering is
what kind of things people do for their reviews, if anything. Does Apple
provide any tools and/or recommendations? If so, what are they?


>
> 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.
>

Good points.

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.
>

Yes, thank you for emphasizing this. So, what might the best methods or
suggestions be to vet an app to help ensure it is not abusing a users'
privacy?

Thanks again for your reply. This was all useful information.