The document provides an overview of the iOS provisioning workflow, which some developers initially find impossibly difficult. It discusses the key components of the provisioning process, including developer accounts, code signing, certificates, provisioning profiles, app IDs, and device IDs. Certificates identify developers to Apple and are either for development or distribution. App IDs uniquely identify apps. Provisioning profiles combine certificates, device IDs, and app IDs to determine whether code is authorized to run. The document outlines the provisioning workflow and purposes of its various parts to help developers better understand the process.

2. When you first start iOS development you are immediately certain that the provisioning workflow and signing
processes are impossibly difficult

3. Things are tedious, it seems like you can't get it right the first time, and things seem to break without touching
them

4. When you have been building apps for 3 years you have been certain for 3 years that the provisioning workflow
and signing process are..

5. If you're NOT superstitious going into the iOS provisioning workflow, you will be once you've got your app in the
Store

6. It can feel like a house of cards -- Today we'll talk about the basics of what's going on, terms, concepts — good
to be familiar

7. Just yesterday we had a run-in with this Writing out all of this for a presentation really helped me understand the
pieces

8. etsy.com/jobs
Hi my name is Lacy and I work for Etsy across the river. I used to work in web development at Etsy and then I
moved into iOS dev

9. etsy.com/jobs
I would be remiss to not say we have three lovely iOS experiences at the moment, we're always working on more

10. etsy.com/jobs
If you're excited about iOS development and you think you'd like working at Etsy, just shout because we're always
hiring good curious dev..

11. A note on Swift, iOS 8 and Xcode 6. Fortunately not a lot has changed, so the topic of provisioning remains very
relevant

12. Apple is always trying to make the process of code signing and prov more transparent and more automatic..

13. The intention here is good but it often falls short. So be aware It's really good to understand the moving parts.

14. Provisioning Workflow
• Developer Account
• Code Signing
• Certificates
• Provisioning Profiles
• (Certs, App ID, Device ID(s), Entitlements)
SO when we talk about the provisioning workflow we talk a lot about 1) dev acct 2) code signing 3) certificates
and 4) provisioning profiles

15. Provisioning Workflow
• Developer Account
• Code Signing
• Certificates
• Provisioning Profiles
• (Certs, App ID, Device ID(s), Entitlements)
To understand each of these we have to look first at the ecosystem and the problems we're solving- where each
of these are used

16. Provisioning Workflow
• Developer Account
• Code Signing
• Certificates
• Provisioning Profiles
• (Certs, App ID, Device ID(s), Entitlements)
Code is delivered to a device as a compiled binary. If Apple doesn't approve of the code, it can't run on an Apple
device, for product quality and for security

17. Provisioning Workflow
• Developer Account
• Code Signing
• Certificates
• Provisioning Profiles
• (Certs, App ID, Device ID(s), Entitlements)
Everything revolves around what "approved" means, Code being approved is a hard rule with a few exceptions,
Jailbreaking is one, changing the operating system so that any app can run

18. Provisioning Workflow
• Developer Account
• Code Signing
• Certificates
• Provisioning Profiles
• (Certs, App ID, Device ID(s), Entitlements)
Another exception is the Apple Developer programs. With the normal program this means getting permission,
usually per-app you make

19. Provisioning Workflow
• Developer Account
• Code Signing
• Certificates
• Provisioning Profiles
• (Certs, App ID, Device ID(s), Entitlements)
An unsigned binary is just a bunch of instructions for the device running the code. This isn't allowed.

20. Code Signing
• Who wrote the code
• Where did it come from
The process here, the ability for the hardware to know if a certain person approved of the code, or wrote the code
is called signing

21. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
Code can be put through cryptographic functions along with public keys and parameters to create long strings

22. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
These long strings are nearly impossible to reproduce without being the authorized party, without knowing the
same secrets

23. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
A signed app means that when the app was built, someone's identity was associated with that app

24. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
The app hasn't been altered since it was signed, so we know who wrote it

25. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
For Android, and in some cases with an Apple device, this is enough to run the code

26. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
For the normal workflow with iOS your code must be submitted to Apple, examined and then they do the final
signing

27. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
When an app runs on your device, the device sees that the code is Apple-approved and there's no problem.

28. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
Alternatively- as devs, when the app runs, your device can see that- No apple hasn't approved of this code- BUT
the code is signed by SOMEONE

29. Code Signing
• Who wrote the code
• Where did it come from
• Cryptography
• Code -> Signing process -> e8b7e220cf0978fe
AND the code, while not approved, can mention the EXACT unique identifier of your device (via an embedded
provisioning profile)

30. Certificate
• Who you are, according to Apple
This is the Apple Developer workflow, the first part is the certificate

31. Certificate
• Who you are, according to Apple
The certificate identifies who you are (or who your company is) and is itself signed by Apple

32. Certificate
• Who you are, according to Apple
Apple can attribute code as being yours based on this identity, and they have control over the validity of this
identity

33. Certificate
• Who you are, according to Apple
Once you establish a Certificate with Apple you have to renew it within a year or it will expire

34. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
The certificates come in two flavors. One is for development, putting code on devices as you write code

35. There can be a lot of development certificates, and if you're working in a large company each developer has his
own Certificate or identity

36. The other cert is a distribution certificate. This is used to identify yourself or your company when you actually
ship code to the App Store

37. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
They are both essentially just identities, but you are only given so many by Apple, and distribution profiles
require dist certs..

38. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
• Built around a key pair
The guts of the cerificate are essentially a public key that's been approved with Apple's signature

39. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
• Built around a key pair
The creation process of your certificate is handled for you by Xcode when you first add a valid Apple ID enrolled
in the developer program

40. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
• Built around a key pair
Alternatively you can create one using the web interface for the developer portal

41. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
• Built around a key pair
Regardless of how the cerificate is created, a key pair is used. There's a private key (as the name suggests you
should..)

42. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
• Built around a key pair
And a public key, which is less valuable since it is part of the certificate itself.

43. The public key is like your name, the private key is like your fingerprint. You should make a backup copy of this
private key in case..

44. Certificate
• Who you are, according to Apple
• Development Certificates, and “Distribution”
• Built around a key pair
Generally this key pair is unique per certificate. If you make a distribution certificate on top of your development
key pair..

45. App ID
• Unique (ish) ID for your app
Next is the App ID, or what's a unique identifier of your app. You need this for signing later.

46. App ID
• Unique (ish) ID for your app
• Used for services (Push Notifications for example)
• Reverse DNS prefix like “com.etsy.”
This is also how services like push notifications will look up your app in the wild. It starts with a reverse-DNS
looking name, like com.etsy

47. App ID
• Unique (ish) ID for your app
• Used for services (Push Notifications for example)
• Reverse DNS prefix like “com.etsy.”
• Bundle ID or wildcard suffix
• “com.etsy.messenger”
The final part is unique per app, and is usually the bundle ID for your app code

48. App ID
• Unique (ish) ID for your app
• Used for services (Push Notifications for example)
• Reverse DNS prefix like “com.etsy.”
• Bundle ID or wildcard suffix
• “com.etsy.messenger”
It CAN be a wildcard which is good for development, but has limitations

49. Device ID
• Embedded in each device
• Used by the authorization process
Next comes he device ID. You don't have to make one up like with the App ID, these are intrinsic to the device

50. You can find it here in Xcode, and generally Xcode will offer to add this device to one or many of your developer
accounts for you

51. Once it's added (or if you want to add it manually) this it the page on the developer portal where your approved
devices are listed

52. Device ID
• Embedded in each device
• Used by the authorization process
A device can be used by any number of developer accounts, but each developer account only gets to add a
limited number of devices per year

53. Provisioning Profiles
• Who YOU are (certificate)
• Device ID
• App ID
So now that you have established who YOU are, which device is yours, and what the name of your app is, let's
look at putting those together

54. Provisioning Profiles
• Who YOU are (certificate)
• Device ID
• App ID
Literally just a plist

55. Provisioning Profiles
• Who YOU are (certificate)
• Device ID
• App ID
Some combination of these pieces is the provisioning profile and it ships with your app, no matter how you're
deploying it

56. Provisioning Profiles
• Who YOU are (certificate)
• Device ID
• App ID
The provisioning profile, the same one you can download from the portal, is built into your app contents along
with the code signing..

57. Provisioning Profiles
• Who YOU are (certificate)
• Device ID
• App ID
While the prov profile is JUST the Certificate, the device IDs and the App ID, but the profile will itself be signed by
Apple so you..

58. Provisioning Profiles
• Who YOU are (certificate)
• Device ID
• App ID
Again- The provisioning profile is what's used to say, yes Apple didn't approve this code PER SE but the device
can run it

59. You don’t need to create a profile JUST to build on your device. A team profile is going to exist by default with all
device IDs..

60. For more specific profiles, this is the first step in creating one

61. The Ad-Hoc distribution option here allows you to actually send the binary out, but a debugger cannot be
attached

62. The second step will be selecting an App ID

63. Provisioning Profiles
• Who YOU are (certificate)
• Device ID
• App ID
In development, the first thing a device is going to do is go look at this profile for validity

64. There are two things you must select in Xcode to get provisioning correct before you build

65. The first is the identity you want to use, aka your Certificate

66. The second is the provisioning profile, which must match both the App ID of the app you're trying to provision,
and your certificate

67. When building, often times Xcode will try to select the right combination of identity and provisioning profile

68. If you've got a lot of these, it's likely Xcode will select the wrong combination and complain.

69. If you don't have a LOT of profiles and identities, somehow it still tends to mess it up

70. It may even offer to fix the problem but most of the time it helps to sort of know what's going on

71. Entitlements
• Game Center
• Push Notifications
• iCloud
• More..
Entitlements are something you may see mentioned but probably won't run across as a new developer

72. Entitlements
• Game Center
• Push Notifications
• iCloud
• More..
Basically entitlements are a list, inside your povisioning profile, which allow the profile to say run the App AND let
it interact..

73. Developer Team
• Team Agent (1)
• Team Admin (many)
• Developers (everyone else)
The team layout is important to know about. For most devs just playing around, they are the team Agent, the
ultimate account status

74. Developer Team
• Team Agent (1)
• Team Admin (many)
• Developers (everyone else)
On larger teams, it's necessary to designate an Agent (only one), Admin (several) and regular developers (who
need their certs approved)

75. This is the account panel in Xcode..

76. Here we see the overview of the profiles and the certificates we have

77. This is the Certificate page in the Dev Portal..

78. This is the list of Profiles..

79. Enterprise
• App ID, but no Device ID(s) required
• Profile says “I am acting as Apple*”
• * Actually this is Etsy (12345)
The Enterprise developer program works a little differently

80. Enterprise
• App ID, but no Device ID(s) required
• Profile says “I am acting as Apple*”
• * Actually this is Etsy (12345)
Essentially in the enterprise program you get a special certificate which says the App ID doesn't need to be listed

81. Enterprise
• App ID, but no Device ID(s) required
• Profile says “I am acting as Apple*”
• * Actually this is Etsy (12345)
Your company then becomes more like Apple, kind of like Apple asterisk, where the asterisk says "actually this is
Etsy (1234)"

82. Enterprise
• App ID, but no Device ID(s) required
• Profile says “I am acting as Apple*”
• * Actually this is Etsy (12345)
Apple can take this away if they decide you are abusing your enterprise identity, and apps will no long be
considered valid

83. App Store Builds
• Not fully signed
When you're building for the App Store, it's funny, you actually end up with less than you do with Enterprise or
normal deployment

84. App Store Builds
• Not fully signed
You get an app that's built and not completely signed yet, so it can't actually run anywhere

85. App Store Builds
• Not fully signed
• Awaits examination by Apple
Once Apple approves the app, they'll sign it and take it from there

86. App Store Builds
• Not fully signed
• Awaits examination by Apple
• Final signing allows apps to run
So this means, for testing you have to build the app once and pass it around, check it and then build it again
before submitting

87. Thanks