swiftstart - provisioning basics

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

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

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

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

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

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

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

http://etsy.com/jobs

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


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


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

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

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

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


• Code Signing

• Certificates



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


• Code Signing

• Certificates



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


• Code Signing

• Certificates



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


• Code Signing

• Certificates



Another exception is the Apple Developer programs. With the normal program this means getting permission, usually per-app you make


• Code Signing

• Certificates



An unsigned binary is just a bunch of instructions for the device running the code. This isn't allowed.

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



• Cryptography

• Code -> Signing process -> e8b7e220cf0978fe

Code can be put through cryptographic functions along with public keys and parameters to create long strings



• Cryptography


These long strings are nearly impossible to reproduce without being the authorized party, without knowing the same secrets



• Cryptography


A signed app means that when the app was built, someone's identity was associated with that app



• Cryptography


The app hasn't been altered since it was signed, so we know who wrote it



• Cryptography


For Android, and in some cases with an Apple device, this is enough to run the code



• Cryptography


For the normal workflow with iOS your code must be submitted to Apple, examined and then they do the final signing



• Cryptography


When an app runs on your device, the device sees that the code is Apple-approved and there's no problem.



• Cryptography


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



• Cryptography


AND the code, while not approved, can mention the EXACT unique identifier of your device (via an embedded provisioning profile)

Certificate• Who you are, according to Apple

This is the Apple Developer workflow, the first part is the certificate


The certificate identifies who you are (or who your company is) and is itself signed by Apple


Apple can attribute code as being yours based on this identity, and they have control over the validity of this identity


Once you establish a Certificate with Apple you have to renew it within a year or it will expire


• Development Certificates, and “Distribution”

The certificates come in two flavors. One is for development, putting code on devices as you write code

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

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



They are both essentially just identities, but you are only given so many by Apple, and distribution profiles require dist certs..



• Built around a key pair

The guts of the cerificate are essentially a public key that's been approved with Apple's signature




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




Alternatively you can create one using the web interface for the developer portal




Regardless of how the cerificate is created, a key pair is used. There's a private key (as the name suggests you should..)




And a public key, which is less valuable since it is part of the certificate itself.

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




Generally this key pair is unique per certificate. If you make a distribution certificate on top of your development key pair..

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.

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

App ID




• 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

App ID




• Bundle ID or wildcard suffix

• “com.etsy.messenger”

It CAN be a wildcard which is good for development, but has limitations

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

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

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

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

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


• Device ID

• App ID

Literally just a plist


• 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


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


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


• 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

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

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

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

The second step will be selecting an App ID


• Device ID

• App ID

In development, the first thing a device is going to do is go look at this profile for validity

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

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

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

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

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

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

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

Entitlements • Game Center

• Push Notifications

• iCloud

• More..

Entitlements are something you may see mentioned but probably won't run across as a new developer

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

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

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)

This is the account panel in Xcode..

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

This is the Certificate page in the Dev Portal..

This is the list of Profiles..

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

Enterprise

• App ID, but no Device ID(s) required



Essentially in the enterprise program you get a special certificate which says the App ID doesn't need to be listed

Enterprise




Your company then becomes more like Apple, kind of like Apple asterisk, where the asterisk says "actually this is Etsy (1234)"

Enterprise




Apple can take this away if they decide you are abusing your enterprise identity, and apps will no long be considered valid

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

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

App Store Builds


• Awaits examination by Apple

Once Apple approves the app, they'll sign it and take it from there

App Store Builds


• 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

Thanks

swiftstart - provisioning basics

Technology

topic of provisioning

provisioning proles

entitlements code

ios provisioning workow

app id

device ids

process of code

apple device