Skip to content

Instantly share code, notes, and snippets.

@rmirabelli
Created January 30, 2019 21:17
Show Gist options
  • Save rmirabelli/7b7243bebea43cad16000cee89ef43b4 to your computer and use it in GitHub Desktop.
Save rmirabelli/7b7243bebea43cad16000cee89ef43b4 to your computer and use it in GitHub Desktop.
How Apple Signing and Facebook interact.
How Apple's app distribution works for iOS:
I'm an iOS architect at a good-sized agency with well over 100 iOS apps developed for our customers and released to the app store. We've got 4 hall of fame awards (none of which I directly worked on), and have a staff of 30 or so iOS developers in addition to other disciplines. I help lead the Dallas/Fort Worth iOS developer meet-up.
I only say these things so you understand that I've been working directly with these issues for a few years.
When a developer wants to put an app on an iOS device, that app needs to be _signed_ with a developer certificate. There are four general release categories of developer certificates: Developer, Ad-hoc, App Store, and Enterprise.
Developer certificates are to be used by the developer for debugging on a single device during application development. This isn't useful for much other than that single purpose. As I'm creating a new build every 5 minutes, Apple doesn't review these.
An ad-hoc certificate allows distribution to a maximum of roughly 100 users. You might use this if you run a very small business or pilot program, or during testing. Apple does _not_ review AdHoc builds at all. During a typical development cycle, I might create 3 or 4 new versions for testing in a single day. It wouldn't be practical for apple to review these either. These apps go directly from me to people I know either personally or professionally, and they trust me completely.
Enterprise builds are meant for large and small companies to develop iOS apps that can be used at their place of business. An example might be a restaurant providing an ordering system for its waiters, a stock trading system used only by the brokers of a single firm, or a catalog brochure app used by high-profile field sales technicians. I've developed several apps in this category. Generally, they won't pass app store review because they're too specialized to be of use to anyone other than a member of that company.
App store builds get the full review treatment from apple, where they determine if the app is using any "private" APIs (which aren't necessarily bad, but could cause problems in future versions of the OS), or doing any number of things that aren't acceptable for general purpose consumption.
What facebook did is created a build of the enterprise variety, and then released it to the general public. This is 100% a violation of the contract that facebook agreed to when it created an enterprise account. Only they are to blame.
If we were to hold apple to account for what facebook did, we would be (in effect) asking Apple to review all of these hyper-specialized apps for no real reason. Apple doesn't need to know about the four different apps that people at my company use to communicate with one another. That's a matter of business privacy. I agree to not let anyone outside my company use the apps, and apple agrees to not review them.
I wouldn't want facebook to be subject to greater scrutiny just because of who they were-- until such time as they violated the agreement. facebook is just as entitled as I am to follow the rules and release internal-use-only apps.
This is why I hold apple blameless. They had no way of knowing, nor should they have. When they found out, they reacted in a forceful manner to fix the problem. Had they not done so, then there would be blame to be assigned towards apple.
I hope this clears up your understanding of my thinking in this manner. I help my clients understand these implications on a regular basis, so if anything is still unclear, please ask away and I'll give you as much info as you want.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment