Well, thank you, and good morning. Welcome to session 301, Introducing Passbook, Part 1. My name's Glen. I'm an iOS engineer, and I'll be joined on the stage in a couple of minutes by my colleague Ken. Ken and I got to work together on Passbook, and we're just really excited to introduce it to you today and tell you a little bit about it.

So Passbook is a new application in iOS 6. It's available for iPhone and iPod Touch. And it's all about the extra stuff that you might have in your pocket. Now, a lot of third-party applications have been taking advantage of barcodes, and they've been doing this in a variety of ways. But the most common use seems to be to allow the user to take some sort of action in the real world. So maybe that's checking in for your flight.

Maybe it's buying your morning cup of coffee, checking in for your movie at the movie theater. And this is great. So customers love this. Developers love it. Merchants really like it. And we think it's really cool. But there hasn't really been any support on iOS for this kind of thing so far. It's just kind of happened very, very naturally. So that changes with iOS 6 and the introduction of Passbook.

Passbook is a single location on your device where these passes can be gathered and accessed very easily in a fun and useful and easy way by the user. And this is what the app looks like when it's full of passes. It's really cool. It's got this nice, clean UI. And you tap on one of these, and all the passes kind of flop out of the way, and the one that you're interested in is the one that's shown on screen.

Now, we've taken care of a lot of the gotchas that come along with using these passes. So, I'm sure you've maybe been ready to use one of these before, and you sort of gesture down to the scanner, and it's in a Safari web page, and the device rotates, and things get crazy, and it doesn't work. And that's kind of frustrating. So, we've taken care of that issue, and we also make sure that the backlight is at a certain brightness level, so that increases the likelihood that there's going to be a successful scan.

And we also made sure that when you, you know, the backlight doesn't turn off right at the moment when you want to scan and causing the scan to fail. So, this is really it. This is the app. But we've gone beyond this, and we've tried to integrate Passbook deeply into the system. And one of the ways we've done that is by using lock screen integration. And this is something that we can provide that a regular third-party application can't, and we think it's where Passbook really shines.

So, and the beauty of this is that you as a developer or a merchant can put your Pass on the lock screen in front of the user at a time or a location that's really meaningful for them. And that's, we think, super powerful. So, that's another great feature of Passbook that we think sets it apart.

Now when that happens, you get this little notification that's on the screen. You slide across it, and the pass slides up, and it's there ready for you to use. And you don't even necessarily have to enter your passcode to access it. So it's super convenient for the user.

So that's what Passbook does in a nutshell. And if you've had the opportunity to install the latest, the seed that we've handed out at the conference, then hopefully you've got a chance to look at it. And what you've probably found is, hey, there's not a whole lot in here, right? And that's why you're here today, so that we can teach you how to put some content in it and how to make it useful. So that's what you're going to learn. We're going to show you how to create passes, how to get a pass into Passbook, and then we're going to give you some design tips as well for making great passes, too.

Now, as I mentioned, this is Part 1 of a two-part series, riveting. And so I want to invite you to come back to Part 2, which is going to be tomorrow in Marina at 4:30. And Ken and Eliza are going to come back, and they're going to show you how to update your passes dynamically using push notifications.

So another huge feature of Passbook is that these individual passes can be targeted by push notifications, much like your application can. So we're going to give you the how-to on getting that to work and making that happen. And then we're also going to talk about PassKit and how you can access model-level information about your passes using our Objective-C API.

Okay, so let's get into some of the nuts and bolts of how you actually go ahead and make a pass. And to talk about how to make a pass, we've been looking a lot at what's on the front of the pass, but we haven't really talked about what's inside of it.

So if you were to crack open one of these things, what are you going to find? Well, what you'll find is that it's basically a file package. And it looks a whole lot like an application bundle with one distinct difference, and that is that there's no executable code inside of this application bundle. Really, the meat of it is this pass.json file. You may look at this and go, wait a minute, JSON? Isn't this Apple? This is a little strange, right? I mean, this seems like a perfect application to throw a plist in there.

I mean, that's what you would usually expect to see in a bundle. But what you'll find as we go through some of these sessions is you begin to realize that these passes are usually delivered, they're usually created on a server somewhere. And so we wanted to choose a technology that would be friendly to a variety of platforms, and so we felt that, you know, this is a good opportunity to do that. So we decided to use JSON.

And so this is a good opportunity to choose JSON because a lot of server people and people who are used to working on other platforms, this is a format that's very familiar to them. So that's why we chose to use JSON. So that's the meat of it is this pass.json file. And then along with that are icons, images, and localized strings. So passes can also be completely localized in any of the languages that we support on the platform.

Obviously, it's up to you to bring your translations, but we certainly support that. So once you have all these elements gathered together in your file package, then we take that and we sign it cryptographically, we zip it up, and the binary that pops out of there is what ends up getting delivered to the users on their iPhone or their iPod Touch.

Okay, so we talked about, at a high level, what makes up this thing. So how do you go about building one of these? So let's take a look at the steps involved there. And you can really break it down into pretty much five simple steps to getting your content together in your pass. And the first is to enter these pass identifiers. So obviously, passes need to be distinguishable from one another. And so we do that with a couple of identifiers. And I'll go into what each one of those are and where you get them and what they mean.

And then you can choose a pass style as well. So we support five different styles, and we'll take a look at each of those. Once you've done that, you can fill out the information that's visible to the user on the front and the back of the pass. And then you can add colors, logos, and images. And once you've done that, that's when you get to add the relevant times and locations where this pass will show up in the lock screen. Very simple.

All right, well, let's talk about what these pass identifiers are. And the first one is this team identifier. So the team identifier is something that's issued to you when you sign up with a developer account on the provisioning portal. It's a 10-character string found on there. And if you're an iOS developer, you're probably pretty familiar with this.

And the reason that we need it is because we use it to figure out which passes in the pass library your application is entitled to access. So it's not just open season for everybody to access. It's not just open season for everybody to get to everyone else's passes. There's an entitlement structure around that. And this is one of the ways that we narrow that down.

It looks like this. The key is just team identifier, and then you just pop in the value right in your pass.json. The next one is a pass type identifier. So a pass type identifier defines a category or a class of passes. And again, you register for one of these on the developer portal.

And it's one of the things that we use to figure out how to group passes, too. So if you remember from the demo on Monday, you saw one of the passes or two of the passes were grouped together. And this is one of the mechanisms that we use to figure out how passes are alike and whether we should group them together or not. And it's just a quick example of how you would enter one of these.

The next one is a serial number. Now, the serial number is a unique number for every pass that you issue. And it's chosen by you. It's completely -- it's pretty much opaque to us. The only thing we care about is that it's a string. And when you take the serial number and you combine that with the pass type identifier, that's how a single instance of a pass is globally and uniquely defined.

So let me just dig into that a little bit more and try and make a little bit more concrete difference between a pass type identifier and a serial number. So let's say that I'm traveling with my family and we're taking a flight and there's three of us traveling.

Each of us has our own boarding pass. But we're all flying on Skyport Airways, so they've issued us our boarding pass. And the likelihood here is that each one of our boarding passes is going to have the same pass type identifier because it's the same class of boarding pass comes from Skyport Airways.

Now, each one of these passes is different, though. I mean, they're issued to an individual. They have a different name on them, maybe some different information in the barcode. And Skyport needs to be able to identify each of these individually. So they issue each pass a distinct serial number, which I've just made trivially short here. The likelihood is that it would be something more complex, like a UUIDU, something like that.

Now, Skyport might also have a loyalty program or a membership program. And maybe that's operated by a completely different part of the company. And they need their own signing cert. And it's kind of a different pass from their boarding passes, right? So in that case, they're probably going to have a different pass-type identifier that distinguishes that boarding pass that has its own certificate.

Okay, so that's pass identifiers. Let's talk next about the different pass styles that you have. And so we've got five different ones that we're currently planning on shipping. The first is a coupon, and the coupon has this kind of perforated edge at the top. The next one is the store card, boarding passes, event tickets, and a generic style as well that you can use for maybe something like membership or anything that we perhaps haven't thought of yet. of yet.

Now, I want you to notice that each of these passes has kind of a distinct edge on them, right? They're all recognizable by the edge that goes around them. And that's one of the reasons why it's really important that when you're making your pass, you choose the right pass style, because this is one of the UI elements that we're using to make passes recognizable to users in Passbook.

So how do you choose a style? Well, it's just a matter of choosing or putting in a top-level key that points to a dictionary of items. And in this case, we want to define a coupon. So our top-level key is just coupon. It could have been boarding pass or store card.

And that points to an array of fields. All right, so let's take a moment and talk about what a field is. So a field, which I've highlighted here, is the smallest and kind of most basic element of information that's visible on the pass that you, as the pass provider, get to define.

Each Passbook has a key that uniquely identifies it, as well as a label. In this case, the label is San Francisco, and then a value, which in this case is SFO. Every field has a default text alignment, depending on the pass style that's chosen. But you can choose to override this if you want to.

You can set a different text alignment if it makes sense for you to, say, center justify the label and the value. And you can also provide dates as well. And if you do that, then you can set a date and a time style on that value. And we will then format the date correctly for the locale that the user is viewing the pass in.

Now, every field is part of a larger group of fields. So in this case, we've got this field which signifies the gate on the top of the pass. And that gate field is part of the header field section. And there's usually only one of these, and it appears at the top. And it's also the only one that's visible when the pass is in the stack.

Then we have the set of primary fields, and the location and size of these fields, these groups of fields, varies on a per-style basis. So in the boarding pass, this is where the primary fields go. And the primary fields usually signify the most visible or the largest pieces of text that are on the front of the pass, the most prominent fields. The next is the secondary fields, so those of secondary importance. And then passes have a different number of optional auxiliary fields as well that you can define. And those are always a little bit small, and you can fit a few more of them on in the pass.

So here's an example of how we might define these fields. So in this case, we want to set up a boarding pass. We set a top-level key of boarding pass that has a set of information inside of it. And we'd like to set up this gate field on the top of our pass.

So it's just a header field array. And we define the key, the label, and the value. And then we also define this change message as well, which was up on the slide earlier, but I didn't talk about it. So the change message is useful in the context when the pass is updated.

Now, if your pass is updated through a push notification or through our Objective-C API, then you can signal us to notify the user that a field changed by including a change message in the field. So what we do is we check the previous pass, and we check the new pass, and we take a look at what's changed.

And if anything's different-- if the field has changed and it has a change message to it, we will show a banner notification with your message inside of it saying, hey, your gate changed. And so that's just a text string with a placeholder, and the placeholder is replaced by the value of the new field.

All right, so I'm also going to put in an auxiliary field here. And the reason I wanted to show you this was just to show you how you can define a date. So here again, we're defining the departure field. And we set the value to a W3C formatted date. So JSON doesn't really define a structured date format. And so we've chosen to use the W3C format.

And you can tell us how to format this by using the date and time style. So in this case, we want this field to just show a short time. So we set the date style to PK date style none and the time style to PK date style short. And that will allow us to format the time in the most brief format available for the current locale.

Okay, there's one other key that I wanted to talk to you about, and it's specific to boarding passes, and it's the transit-type key. You may have remembered on the previous slide there was a picture of this airplane, but obviously boarding passes are useful for more modes of transportation than just flying, right? So you can specify a couple of different kinds, and we can draw a train there or a boat there or whatever you specify.

Okay, so that's fields. Let's take a moment and talk about what color options are available to you. So there are a couple of handles that you have to control the color on the pass. And the first and obviously the most obvious is the background color, right? So in this case, we've chosen brown. We'll take the background color that you specify and we'll apply a mild gradient to it and a little shine. And that's what we then use as the background color of the pass.

You can also specify the foreground color. The default for this is usually just white, but you can set it to whatever works well for the background color that you've chosen. And then we'll also take the background color and try and figure out a good color for your labels, too, a color that we think works well with your background color. But if you find that you don't really like the option that's been chosen for you by default, you can also override this by specifying a label color.

Okay, so what other things can you specify in your pass? Well, of course, there's logos and images, too. So the first is the logo and the logo text. Now, mostly in terms of images, it's just a matter of dropping an image that's named correctly into your pass package, and we will use it accordingly, depending on how it's named. So this one is logo.ping, or logo at 2x.ping, and it's the coffee cup that's shown in the top left-hand corner. In this case, it's just a small, iconic logo.

And so because of that, because it doesn't contain any branding inside of it, we can also use logo text, which is specified in your pass.json file, and we'll draw some nice text at the top, depending on what you tell us to draw up there. And this is actually the way that we recommend doing it. We recommend using an iconic logo. And then adding -- using the logo text to, you know, put the name of the pass or your company name or what have you.

The next is the background image. And the background image is kind of an interesting one because it can be used in a couple of different ways. So in this case, on the store card, we're using it as this strip image that gets put up on the top half of the pass, which has kind of a nice effect. But if this were to be an event ticket, then it would be treated a little bit differently.

We would then apply a blur to it and set it as the background to the whole pass, which gives us a really cool event ticket look to it. And it's pretty neat. So you can also specify a thumbnail image as well that we'll use that has meaning on certain pass styles as well. In this case, we've just chosen the clear version of the same background image.

Okay, so we've talked a lot about what's on the front of passes. How about the back? What's the back all about? So, on the back of the pass, at the top of your pass is usually a settings section, and you don't have any control over this. These are settings that we put into the pass to allow the user to control the notification settings and whether your pass is shown on the lock screen. But below that is a set of pass fields or back fields that you can provide, too.

So, right alongside your header fields and your primary fields, you can specify back fields. And this is really useful because we allow an arbitrary number of back fields on the back of your pass. And what will happen is, as you add more, we'll just add a scroll view so that you can scroll through them.

This is helpful if you have fields that are important enough to be on your pass, but don't necessarily need that prime placement on the front of it. Things like terms and conditions, which may be kind of long. And so it's a really useful thing to have. There's one other thing that I want to tell you about that you can insert onto the back of your pass, and it has to do with your applications.

So it's important to remember that passes can exist completely independently of third-party, of App Store applications, which we think is an awesome feature. It means that these can be distributed around, they can be given to users, and they don't necessarily have to have a third-party application associated with them to be useful.

However, I mean, we recognize that this is a great place, it's a great vector for you to direct your user at your application, which may have a bunch of utility and uses that aren't covered by Passbook that you could be providing. So we wanted to give a nice spot to allow you to send users to your application, and they'll be able to open your app directly from the back of their pass and even download it directly there, which is super cool.

It's super useful. And the way that this works is that you give us an array of numbers, and this is your Atom ID, you may be familiar with that, or your iTunes Store ID. And we'll take the first one that matches for the device that you're on, and we'll show that in a view on the top of the pass. Now, you notice I'm not showing it here, it's because it's not available yet in Seed 1, but it will be, this feature will pop up in a forthcoming Seed.

Okay, so that's Passbacks. Now let's talk a little bit about barcodes, which is basically what we're trying to dress up here, right? So we support three types of barcodes in Passbook. We support PDF417, Aztec, and QR. Now, if you know anything about barcodes, you probably understand that these are all 2D formats.

So we don't support 1D formats in Passbook. And let me just back up a little bit and kind of explain to you what's the difference between a 1D format and a 2D formatted barcode. I certainly didn't know before I started working on this. So a 1D formatted barcode is the kind of barcode that you're used to seeing, like, on your grocery store items or, you know, on merchandise that you buy. It's the vertical black stripes, kind of the zebra stripes, right? Now, an interesting thing about 1D barcodes is that... They're usually, not always, but usually scanned by technology involving laser scanners.

It turns out that laser scanners really don't work too well on a backlit LCD screen. So if you use a 2D barcode, that requires a different kind of technology to read the barcode. And what it needs is a digital imaging device, which works a little bit more like a camera. And it turns out that digital imaging devices work really well for scanning LCD screens. And so we... We wanted to make sure that we would ensure success for our users when they go out there and scan their devices.

And so we only support 2D barcodes because if you put a 1D barcode on your pass and then the user goes and tries to scan it with a laser scanner, it's not going to work too well. So 2D barcodes are supported. PDF 417, Aztec, and QR. And we think that that covers basically all the bases for the different 2D barcode readers that are out there. To be honest, most of the ones that... We've looked at support all of these formats. But we figure these three formats are enough to cover pretty much anyone.

So the way it works is that you provide us the message in the form of a string that you'd like us to put in the barcode, and you tell us how you'd like us to encode it, and then we draw the barcode. Now, one interesting little thing is that you can also provide optional alt text that goes under the barcode, and that's shown here.

So some merchants have the requirement that if they're at the point of sale and the register goes down, or the scanning device goes down, or the scan isn't being successful, that they have the opportunity to just punch in the number manually. And so this is useful for that. You can use alt text to put in a message below the barcode, which may be useful in the case that it doesn't scan. And it doesn't have to be the same as the message that's encoded in the barcode itself.

All right, so let's take a quick look. Let's look at an example of how you create one of these barcodes. The first thing you do is set up the top-level barcode key, and that's got a dictionary of items inside of it. You set message encoding. So in this case, we're using ISO 8859-1, which is otherwise known as a Latin one. It turns out that this is a very common encoding for barcodes, so chances are you're probably going to use this.

But obviously, it's up to you to know what your scanning infrastructure is like and what kind of encodings your scanners support. So let's go ahead and do that. So you can provide us with a number of different encodings. And then you set the message that you'd like to show in the barcode. You can provide optional alt text, and then you tell us the format of the code that you'd like us to draw, and we'll draw either PDF 417, ASTEC, QR. In this case, we're drawing a PDF 417.

OK. So now I want to take just a quick moment again to talk about relevancy, which is, again, what we think is really interesting about Passbook. And relevancy allows you to put your passes on the user's lock screen at a time or a location that's meaningful to them.

So how does this work? Well, as I said, you can do it via location. And the way this works is that when the user wakes up their device, we do a really inexpensive location lookup right there and then if they have passes in their library that have location information.

And we take a look at the different passes in their library and look at whether they have location information. And we do a matching to try and figure out if we're within a certain radius of the locations provided on the pass. You can provide up to ten coordinates of interest in your pass.json. Now, this is a number that we've chosen.

We're really interested in feedback about what numbers are good for you and how many we need to support. But obviously, we've got a lot of considerations to balance in terms of power and performance issues, right? So talk to us in the labs about this. We're really interested in your feedback.

The other way you can make your pass relevant is by setting a relevant date. And obviously really good for time-sensitive applications, like boarding passes and event tickets. So you provide a single date of relevancy in your pass.json. And once again here, the window around that time is tied to the style of pass that you use. So here's an example of how you might set a relevant location and a relevant date on your pass. In this case, locations key points to an array of coordinates, and then a relevant date, which again, that familiar W3C formatted date.

Okay, so that's how you make your passes relevant on the user's lock screen. Again, a really cool feature. Puts your pass in front of the user when they need it. Locations and dates are limited. They will be limited in some way in terms of the numbers that you can provide, but it's really important to understand that you can update them.

So, come back to session two, and we'll tell you how to update your passes with push notifications and through our PassKit API so that you can start to really think about interesting things that you might be able to do in your app's UI to give the user some control over that, or maybe even set those parameters for them based on intelligence that you might have about what they're doing and how they're using their passes, right? Okay, so one little word about localization as well. Obviously, passes can be fully localized in any of the languages that the platform supports, and this works a whole lot like app localization works. So in your pass.json, for example, you've got a field defined, and the value is, you know, ohmystars. You want that translated into French.

You set up a French.lproj folder inside your file package, create a pass.strings file, set that value from your pass.json as the key in your pass.strings file, and then your translation for that is then the value in your pass.strings file. And we take care of substituting the right one in to your pass when it's shown in a particular locale. Thank you. All right, so that's the nuts and bolts of how you create a pass. It's pretty easy, but I want to invite Ken up to come and give you a demo of how to do it from front to back. Please welcome him.

Thank you. So let us suppose, for the purpose of this demo, that we all work for Oceanic Airlines. They somehow got past the five person limit for the conference. And we just went to the keynote, and we're like, this is amazing. We really need to start doing this, because what we're doing right now is terrible, and we need to fix it.

So if we're in that situation, and we're super excited, but what do we start to do? How do we actually go about making a pass just from scratch? Or where do we start? And the answer for that is that you should start by downloading the sample materials, because you can basically copy it and change a bunch of stuff. And that's what we're going to show here.

So if you go and search on developer.apple.com for the materials associated with this session, you'll find the stuff that I'm going to be working with here. Or if you're watching the video later, just go search the sample code for passbook, and you should be able to find it.

But so one of the things you're going to see is you're going to see a pass-- these sample passes we give you. And if you click in there, what you're going to see is basically what we were just showing you a minute ago, a bunch of different directories, which are the blown out contents of these pass packages that we were just looking on the board. And then also, we give the fully zipped up signed version of that, which is directly something that you can-- Put into Passbook a pass.

That is a pass. The PK Pass is the pass. So if we're in this situation, what's the first thing we're going to do? We need to figure out which one to start from, which one to copy and start tweaking. And let's suppose that we're not really very bright.

So we don't really know if, even though we're an airline, we're not sure if we want a coupon or a boarding pass. So we decide to go and look at them on the phone. And to do that, what we're going to do is just grab all these guys, the PK Passes, and email them to yourself. So let's suppose we do that. Thank you.

So we have this email that now has showed up on our device, and it has these five different passes on it. And we give you one sample in each of the different styles. So, you know, they look pretty much like Glen was just showing you. And obviously in our case, the one that we're really going to want is the boarding pass.

So we go back. and we say, all right, I'm going to take that-- did I get it? Yep. I'm going to take that boarding pass directory. I'm going to copy it and duplicate it. So now we have that. And it has the pass.json. Then it has a bunch of art.

And then I have to go and I have to plead with my designer to draw me some artwork for this pass, which I have-- which I get. Or if--whatever. But then I do notice one thing that my designer did, which is that my designer drew a version of the logo that contains all of the name of our-- you know, all of Oceanic Airlines, whereas the boarding pass that was here didn't have that. The logo just had just this fin from the plane on it.

So we're going to have to sort of account for that difference when we are doing our pass. Let's just go ahead and rename it so we don't get confused. And also 'cause I have a script that's looking for that name. First, let's go ahead and change out that art. So we drop in the art.

Okay, looking better already. And then we go to change this pass.json file that we were just talking about. It looks like this. Just a big JSON file. And we need to make this into ours. So we're just going to do sort of the least amount that we can here. I'm going to change the pass type identifier. We'll be talking a little bit more about these later, but again, this is sort of like the class. All boarding passes that Oceanic puts out are going to have the same pass type identifier.

They'll all have different serial numbers, but we'll leave that out. So we'll leave that for now. Let's see. We are not Oceanic Airways. Sorry, we are Oceanic Airways. So let's change that. And the reason I'm fiddling with this is because this is where the text came from that we see in mail. I'll show you again. So that would be wrong if I didn't change it.

This logo text is the additional text that goes next to the logo, and we don't want any because our logo is already built into the art. So we remove that. We have different colors from our designer. He wanted white foreground. So we're going to go ahead and do that. And we're going to go ahead and do that. We have different colors from our designer.

He wanted white foreground. So we're going to go ahead and do that. We have different colors from our designer. He wanted white foreground. And we need some kind of background color. So we went with 42, 4, 8, 15, and 4. Let's do that. And that's pretty good. But just to give an example of something else changing, let's say we wanted to add a field.

So in our secondary fields right now, we just have a passenger. So let's just copy that. And we'll make a boarding group. Change the key because these have to be unique. So we went with 42, 4, 8, 15, and 4. Let's just copy that. And we'll make a boarding group. Change the key because these have to be unique.

and we'll say that our boarding group is Premier. I don't actually know if that makes sense as a boarding group, but we'll just go with it. And let's just say that to make it look nice, we looked at it on the device and we found, actually, you know what? We really want the text to be right-aligned here.

Which we do like that. OK. So now we are pretty much done, at least if we're willing to make very small changes like this. So we need to sign it and zip it up before we can actually look at it on the device. But that seems a little bit boring. So instead I'm going to hit this do magic command. And now we have done magic.

So now we have a fully zipped and signed pass. And I promise to you that before the end of this talk we'll explain what that command is and we'll go look at it. But this is now-- In fact, if I just copy this and change its extension to .zip so that the finder thinks it's a zip file, We can see if we blow that out, it is indeed what we just made with a couple extra files, which we'll be talking about. Okay, so get rid of that again, and we grab this and email it to ourselves without noise this time. And we go back to our inbox, and it looks like that. So we seem to have succeeded.

Yay. So now there's one more thing I want to talk about before I turn it over to Glen for now, though I'll be coming back later, and that's a little bit of debugging. So let's say that we screwed something up, okay? We're just editing this JSON file, and it just seems the possibilities for messing something up seem quite large. So let's say we screwed up something pretty dumb, which is that we typed serial number instead of the proper spelling. Damn you homophones. So then we did this again. We zipped it back up and got the file.

And emailed it to ourselves. And what is going to happen? So, uh... What we're going to see is that when we try to look at that, it's just going to look like a generic attachment in mail instead of looking correct. And then when we go back to Xcode to debug this, how do we figure out what was wrong? Well, if we look at the organizer and we look at the console for the device-- Oh. That's good, but it's in there somewhere. Just a second.

There we go. Okay. Then we get this error message which says that we are missing a required key from that dictionary, which is the serial number. Okay? It's not going to complain about the fact that there was some key it didn't recognize in there because for future compatibility, maybe we will be adding keys.

But it says there was a required thing that wasn't in there. So this is your tip-off. So basically, while you're trying to do this, you should go look at the Xcode organizer and look at the console whenever things don't seem to be working right because we log a lot of useful information.

Maybe the last thing to note, since it's along that line, is about testing. How should you test? You should, at least before you ship, you always have to test on the device. Put it on the device. Show it. Generally, if you're making a pass, you are also in charge of the other end of it, the scanning.

Go get a real scanner of yours and make sure it works because different scanners, it should be fine, but it's like not doing this is like trying to write a web page and never actually looking at it in a browser. It's just not well advised. So, so that's it. So with that, I will turn it back over to Glenn to talk about some of the stuff we skipped.

All right, thanks, Ken. So we talked about how to create your passes. Ken showed you how to do that. But he also talked about some magic stuff that was happening, right? And so let's -- we've talked about the contents of your passes. talked about pass.json, localizations, icons, images.

But we've kind of glossed over this manifest.json and signature stuff at the bottom, right? And this is really how we cryptographically sign your pass. And so we're going to go into that just a little bit in this session. So how do you deploy your passes? Well, you deploy your passes by visiting the portal, and the first thing you need to do is set up a new pass type identifier.

And once you've done that, that'll enable you to get the certificate that you need to actually create your pass and sign it correctly. You sign and zip it up, your pass package, to create the pass, and then what pops out of that is the binary that you then deploy to your users.

So if you've been poking around the developer portal in the last couple days, you've probably noticed this new section here. It's the Pass Type ID section. And this is where you go to visit to set up your new pass type identifier. So you provide us with a description and an identifier.

And the only constraint is that it has to begin with pass dot. The rest of the identifier is kind of up to you, but obviously it has to be globally unique. So we recommend using reverse DNS just because that reduces the chances that you're going to have a name collision.

Once you've got that, then it's time to sign your pass. So there's a recipe to doing this, and Eliza's going to talk about it a little bit in Part 2. But what we decided to do, as Ken said, is give you some sample code in the session notes to allow you to do this really quickly, because today's session is all about how you create passes, right? And so we don't want you to have to worry about this too much. So use the Sign Pass tool in the included session resources. But again, understand that when you deploy these things, the chances are, because they're signed, they're going to be generated on a server somewhere usually.

And so you're probably going to need to roll your own implementation of this signing and zipping recipe. But not to worry, we've provided you in source form the source of the Sign Pass tool. But in addition, we've also given you a reference implementation that's in Ruby that does it as well.

So once you've created and signed and you've got your PK Pass file, well, how do you get it to your users? There's three ways that you do this. The first is one that you've seen already. You can send it as a mail attachment. So if you send it as a mail attachment, if you're on iOS 6 and you're in mail, it'll recognize that this is a PK Pass file, and it'll show you that UI that you saw earlier and give you that ingestion experience where you can tap on it and elect to add it to your pass library.

The other way that you can do it is by sending your users a URL or having them navigate in your web page to a particular URL. And the way that this works is that as long as you respond to the URL request with this particular MIME type, then Safari will recognize that and again present that same pass-adding UI.

Lastly, you can use PassKit to do this using our Objective-C API in your application. And again, it's a really simple -- it's just a matter of presenting a view controller, and it will, again, present this opportunity for the user to add your pass to their PassKit library. All right, so I'm going to bring Ken back up one more time to just show you a few more of the details of the magic stuff. Thank you, Glen.

Okay, so now we're going to go into what was going on when we were trying to sign this pass. As Glen was saying, another item that's in the materials that we're giving in the sample is this project called SignPass. and it serves two purposes. One is as a reference when you're trying to go implement the algorithm yourself, because you might have to do that because you're not in an Objective-C environment, like a server.

Or when you're in the kind of situation that we're pretending we are now, we just want to see a pass, you can also just use it and just run it. And in fact, you can just run it yourself on your server if you happen to have a Mac OS X server. It's just not super likely.

So if I just hit Command-R, so that's just running it with no arguments, which produces this usage message. And it says signpass-p is a path to the pass, and then some other stuff that we're going to ignore for now. Though you can look through the source code, of course, if you want to see what it is. OK, so having built that, now I'm in a position to be able to show you what this do magic command was. It was not much.

All it did was invoke signpass-p, and then the path to-- to the unsigned package, to the contents of the package. OK, now why wasn't there even a cert there? Well, there's a cert because it's in my keychain. So let me show you how that works. We're going to go get a cert.

So this is all documented, and it's described both in documentation and in the text on the portal. But because it kind of bounces around between different places, we thought it would be nice to just sort of walk you through getting a profile. So-- take note of what time it is if you want to be able to go back and look at this part later. So we will go into the portal.

We go into the iOS provisioning portal. We grab pass type identifiers, pass type IDs. And then from here, we say we want to make a new pass type ID. OK, we'll call it boarding pass. This is not important. It's just a description in the UI. And we're making pass.com.oceanic.boardingpass.

OK. And we go ahead and do that. Now we're to this stage. We've now created the pass type ID, but there aren't any certs associated with it yet. So tap Configure. Configure again. Now it's saying to launch Keychain, so I'm just going to do that. I'm going to select certificates first.

Request a certificate from a certificate authority. Save to disk. Now it's a desktop. So at that point, we have now saved that out to disk, and this is what this text is telling us to do in the portal. Hit continue. Choose the file that you just created. Generate.

And Now it's actually making the cert. And the reason why it's bouncing back and forth like this is to avoid exposing the private key to Apple, which makes it a little bit funny, of course, when you have to go between applications. Anyway, so we eventually download that guy. And we just double click it, and that will add it to Keychain.

The way this sign pass tool works is that it looks at your pass that you're trying to sign. It grabs that dictionary and gets the pass type identifier out of it. And then it has this integration with Keychain. It runs through the certificates in Keychain, looking for one that has a name that matches that pass type identifier.

And that's all it does. And then it uses that to sign it. So when we click that Do Magic-- let me get rid of this and we can just look at it-- it just sort of spits out the information about what files it stuck into the signature, basically. Stuck into the manifest, really. But that's what it was dealing with. And so that's pretty much it.

Oh, there was one more thing I did want to say, which is that because of the way the sign pass tool works using your pass type identifier, if you go to just directly sign these passes that we gave to you, they won't succeed in signing, because you don't have a cert for this pass type identifier.

You know, this pass type identifier is skyport.boardingpass. And you're not going to be able to get that. So in order to be able to use the sample passes, you always have to change this to your actual identifier that you registered on the portal. Anyway, with that said, that is all I wanted to go through. So I will give it back to Glenn to finish up.

All right, thanks again, Ken. Okay, so we've given you the tools that you need to create passes from front to back. We've talked about what's inside of all of these things. But now we want to give you some design tips for creating great passes. Now, you know, Passbook is a super simple application in terms of, you know, the UI that's presented to you. It's filled with your content.

So it has a very clean and simple design aesthetic, but it does have a design aesthetic. So we want to give you some tips for how to fit into that and be successful in creating passes that look great, make Passbook look great, and, you know, delight your users, right? So, you know, Passbook is a super simple application.

So the first thing I want to let you know is that we've done a lot of experimentation. We designed a lot of passes. We did a lot of stuff. And what we found is that vibrant, solid colors really work best. So use those. And, you know, this just really makes the cards pop and look really nice.

The other thing is that, again, I want to encourage you to make sure you're using the correct pass style. So, you know, one of the few sort of UI elements that's... So part of Passbook is this...the edges that the passes have. And so that's a recognizable way for users to understand what they're looking at very quickly. So make sure that you're using the right pass style for your application.

Next, in terms of logos, if you're taking our advice and you're using these nice, vibrant, solid colors, then chances are that a solid white logo is going to look pretty good. And, in fact, those tend to work best, right? So if your company or your brand has a monochromatic version of your logo, which a lot of brands do for newspapers or what have you, then we encourage you to use that monochromatic version in white against a nice, solid background. It just looks good. Now, obviously, there are always exceptions to the rules, but these are just tips that we've discovered along the way.

Okay, so, and in terms of layout, you know, again, it's a very simple, clean aesthetic, and we just want to encourage you to avoid the temptation to just cram as much information in these passes as you can. Be very selective about the kinds of information and the pieces of information that you're putting in the front of your pass. Only select the most important things and only the things that really need to go there.

And remember that you have the backfields array as a tool as well to put information in your pass that maybe doesn't need that prime placement, right? Remember that users are using this on the go, and they're glancing down, and so you want to communicate to them quickly, you know, what the most important pieces of information are.

The next thing I just want to mention is that you really need to keep your passes accessible. And I almost hesitate to even talk about this, but I'm going to anyway. Don't bake semantic information into your background images or your passes. One of the things that we could have done was just give you a big old canvas that we animate around on and you paint on.

But it's not useful in a lot of ways. We can't do interesting things with your data if we don't have it as data, if all we have is pixels. And one of the very useful things that we can't do is we can't make your cards very accessible. So that's why we've defined this format. That's why we've done it this way. That's why we've sort of created these rails for you to be on.

And so, you know, avoid the temptation to just, like, bake super important information right into the artwork that's on your pass. The next thing is to use header fields sparingly. I mean, you'll notice in our sample deck, like, we don't even really use it that much. You only want to use this if you have a super important piece of information that you need to communicate to the user that needs to show up in the Passbook. And the stack view, right? So, like, you know, the gate is, like, that's pretty important, right? But you don't want to just use it because it's there. Only use it if you really have a purpose for putting something up there.

Next is that different businesses have different requirements, and a lot of people are already in this barcode game, and they've settled on a format, and that's great, that's fine. We've selected a variety of formats to support, but we just want to tip you off that if you're starting from scratch and it doesn't make a difference to you, one thing to note is that if you use a square-oriented barcode, it's going to eat into your vertical space quite a bit.

So what we have to do is we have to scrunch down those fields that are on the top of the pass, and it makes them a little bit smaller. So if it makes no difference to you, you might want to consider trying a landscape-oriented barcode, because it'll give you a little bit more vertical room, give you a little bit more space on the page, and let things kind of breathe a little bit more.

Okay, so if there's one thing that you can take away from this section of the talk, it's keep it simple. Really keep it simple. Don't avoid the temptation to overload your users with information on the front of your passes. And one other thing that I just want to mention is that, you know, a lot of these passes already have analogs in the physical world already, right? There are boarding passes out there, there are event tickets, they're usually printed on a white piece of paper.

And avoid the temptation to, you know, take your physical thing that already exists and just do a one-to-one copy and be like, okay, you know, I'm going to take this and just put it into Passbook and that's going to be my pass, right? It's kind of boring. We want Passbook to be fun, usable, and we want it to, you know, the user to be excited about going there, and it's got all these fun animations.

So, you know, take the opportunity to design. Design something to communicate your brand by designing instead of just copying something that's already there, right? And essentially making a Passbook full of boring white passes. So keep it simple, be creative, and if you do that, if you do those things, you'll get fantastic results.

And, you know, just here are some examples of really simple passes that look awesome but are super simple. And if you follow these principles, then you'll get results like this, and you'll make Passbook. fun to use for people, which is really important to us. Okay, so that's all I have to say about design. For more information, contact Paul. He's our application services evangelist. Check out the docs. Check out the developer forums. And thanks for coming. I really appreciate your attention. Go out there. Make awesome passes for Passbook. Thanks.