Hi and welcome to Integrating Passbook into your Ecosystem. My name is Joelle Lam, an Engineering Manager at the Apple Store App Team, also the Engineering Lead of Apple Store Gift Card in Passbook from WWDC to its launch in October. Last year iOS 6 announced Passbook. Passbook was this way you can include your boarding passes, your movie tickets and more on your iPhone or your iPod Touch. Now, us being the Apple Store Engineering Team, we knew we wanted to be part of this, we knew we were missing out if we didn't get involved in the Passbook Ecosystem. So, very quickly came Apple Store Gift Card in Passbook.

Now, I'm not from the Passbook Team. If anything I'm more like you, I sat there and watched the WWDC sessions, I'm like an external developer looking onto iOS technologies asking, "How do I enrich the user experience? How do I bring to life some everyday things, these everyday things that used to exist in our pockets?" OK. So, let's do a quick overview. We're first going to talk about Apple Store Gift Card, this is all about pulling back that curtain and showing you a little bit about what we did and why we did it.

Then we'll go into leveraging existing systems. I thought this was so important because some of you guys are out there, you have these huge systems and you're wondering, "Can I bring Passbook to my Ecosystem?" You have SAP downstream, asking a DBA to create a few databases is going to take weeks, right? And then I have to do a security review just to get the ACLs to talk to my downstream systems. So, leveraging existing systems is all about bringing Passbook to your Ecosystem no matter how complex it is.

Then we'll talk about determining complexity. This is kind of an experiential wisdom of how to determine the level of effort to build your pass. And finally, we'll do some web services tips and tricks. These tips and tricks are separated by complexity level so there will be something there for every single one of you. So, let's get started.

Apple Store Gift Card is all about giving the people you care about the products you love, right? If you look at this life cycle of our gift card somebody will go into the app or on the website and they'll purchase a gift card and this gift card will then get emailed to the giftee.

So, when we're delivering that card, we're actually delivering an email with a link in it which allows that person, the giftee, to receive that card. Finally, that card is opened within Passbook and the user can look at the pass. From there the Passbook can-- the gift card can be brought into a store, used online and redeemed.

You can then use it to purchase something. Immediately when that purchase occurs, we send an update and the update will actually update the pass and the giftee can now see their new value in the pass. Of course if they have a value left, they can continue that cycle again. OK. So, delivering the pass.

Apple Store Gift Card is kind of a different-- a little bit of an advance pass. You'll see that its flow of giving a user pass is different than what you would expect. It doesn't actually use a Companion App, we use quite a few other avenues. So, if you get overwhelmed as you're looking at our lifecycle or as you're looking at our flows, don't worry, when we get to determining your complexity, you will realize that you don't need to do everything we did but there'll be a lot of good things you can carry away from this, OK? So, how many guys have the Apple Store App? Good. Good, that's like 60, 70 percent, I like it. How many of you don't? You guys, OK.

[laughs] I'm impressed though, that's honest. So, step one, download the Apple Store App. Open the App and you get to look at the passes. For me, I'm going to purchase a pass for-- one of my coworkers, Sonal. She's been working really hard and she's kind of new to Apple. She doesn't have all the products yet. So, I'm going to buy her an Apple TV, I've picked out a nice pass here. 110 dollars should buy her an Apple TV, right? Then I'll put a nice little message in there, say, it's to "Sonal" and from me.

And I'm telling her to enjoy her Apple TV. She's worked really hard and deserves it. OK, then once the order is submitted, the order is inducted, and an email gets sent out. This is just like every single Gift Card email that we previously had. Sonal will read this and go, "Cool, I got an Apple TV, this is so great." She's going to open it up. So, notice the add to Passbook link, click on it and bringing her to mobile Safari.

Now, this is our opportunity to basically tag the pass with the ten nearest Apple Stores. You can use iBeacons now if you prefer to do that or you could use both. Even if she ever forgets that she has this and she walks near one of our stores, she'll remember. Then she clicks to create the pass and there it is, her Apple TV ready for her to pick up.

OK. So, what were some of the Apple Store's goals in building this pass? Passbook was an additional avenue to get Gift Cards to users. It's not like I was able to re-imagine my backend systems, I wasn't able to re-imagine the paper gift card. if I had a choice, I would do away with the paper gift card entirely. But I didn't have a choice. Those avenues had to continue to co-exist with the Passbook avenue.

So, really, Passbook is complimenting the entire system. Existing avenues shouldn't get harder, right? And then a great find that we stumbled upon. Last year, when we were watching the Passbook presentations, we thought, "oh, ok, so we have to make sure we have a Companion App and somehow this has to work with Apple Store App even though the gifter is not the giftee" and it occurred to me that our Companion App is not really required.

In fact, there's a larger base of users that have access to mail. So, if you can detach yourself from the requirement of a companion app, you actually have access to much larger user base, right? There's more of a chance that they'll see my Gift Card if it goes to your mail if it required an app download. Not everyone in this room has downloaded my app. But everyone in here has access to mail. Ok so, no companion app required. Then lastly, integrating with existing systems.

I couldn't touch or change many of the systems that I have below me. So, we have to make sure that we minimize our changes and we'll talk about that one little later, OK? So, Sonal, she works really hard, she doesn't go to the mall a lot, but now she's in the mall and she's walking along and she walks across the Apple Store. And boom, her pass lights up and says, "Hey, don't forget to use your gift card -- go get your Apple TV." So, she goes in, she picks up her Apple TV, and opens up her pass and says, "Yes, I want to purchase.

You can see we use the QR code there. Lucky for us, our point of sell devices are iPhones. So, we simply have to enable that camera and scan the QR code. And lucky for you, AV Foundation is going to do all that work for you. You don't have to think about shake factor and a lot of things that we have to be concerned about. So, definitely take advantage of that. But let's say she never gets to the mall.

Let's say she still wants to get her Apple TV. She still has to be able to purchase on the web, right? She has to be able to turn that pass over and read in clear text the gift card and a pin number and make the purchase. So, we actually have to provide the data both in the QR code and on the back of the pass in clear text.

Make sense? Good, I see some of you nodding. OK. So, using the pass, you'll see this kind of theme or reusing and leveraging existing systems, we reused the point of sale devices, we didn't have to replace them. If you need to, write an app and leverage AV Foundation to use optical scanners.

And then we have the support, the web. We even have to support the phone. Yes, people still use a phone. But something that surprised us a little bit-- at least the surprise for me was the human factor. Apple have some of the greatest retail employees. But as you know, retail employees ebb and flow based on the seasons. So, when we first decided to launch the Passbook, we've trained a bunch of people. But there was no guarantee just a few months later that the people that we trained we're going to be the people we would go live with or launch with.

What I've learned from this is how important it is that we design and develop even our point of sale devices that only our sales agents use to make sure that it's almost impossible for them to make a mistake. So, what kind of mistakes could they have possibly made, it's just an optical scanner, right? Well, actually one of the Apple employees, they walked into the Apple store with their Passbook and the sales agent was trying to laser scan this QR code and he's like, "Why isn't this working?" You just sitting there looking, "Should I say something?" Well, retail employes usually see this one dimensional bar code. A two dimensional bar code to a retail employee may not be that different.

So, bottom line is target user experience consistency. If you're trying to be very consistent for every user, you'll realize you cannot train every sales agent. You just can't. So, build into your point of sale device. Make it obvious what the sales agent should do. Add a button there that says check out with Passbook. Make it very clear so nobody is confused. Both the sales agent and the customers.

OK, updating the pass. This is the web services portions, right? This is the feedback loop bringing to life your pass. Once a redemption occurs, if you can tell the user that something has happened it's so much more rewarding. If I have a gift card and the sales agent makes the purchase and almost seconds later the value updates and you're like, "Oh OK, what I just did actually happened." There's kind of a satisfaction that occurs. So, update your passes, use Apple Push Notification service. Super easy to do and bring that feedback loop all the way around. Feedback to the user, feedback to your sales agent. Apple Store Gift Card. OK, let's move on.

Leveraging your existing systems. If you come from a larger organization or an organization even that's been around for a while, your systems architecture diagram might look something like this. You start with an App and this is the App that we purchase with, right? And it talks to our applications and services layer. And then it talks to our order processor and then it-- the order is inducted by SAP, it's probably written to a database.

We notify our physical gift card services. Hey, we have a gift card that we need you to generate. And when that card gets generated it probably writes to a data base and then an e-mail gets sent out and on and on and on and there's a lot of boxes there, right? That's really all you're thinking about right now and I would agree with you, there are a lot of boxes there. So, the goal is to identify all those boxes that do not matter.

Maintain only the relevant boxes. Maintain only the ones you need to change. So, then you're pushing into this black box all the things that are no longer relevant, and you can push and push and push and identify those things you don't need to touch until you end up with something that looks like this. There are four interfaces no matter how complex your Ecosystem is, there are four interfaces you must work with.

Number one, creating the pass. For Apple Store App we used e-mail to do this right? There is a link in the e-mail. What is the interface in which you generate or create and get that pass to that user. Number two, source of truth. This is the system that knows the ultimate value of your pass. It's what your pass primarily represents.

Number three, redeeming your pass. The interface for redeeming your pass, how do you use that pass? And number four, this is the call back for the update. Once the pass has been redeemed, how do you know that there has been a change or once the pass has been changed in any way, how do you know the pass has to be updated? So, four interfaces, right? Then, you need to identify the common factor between all four of those. The common currency.

For us I used GCN here but it's a Gift Card Number. All of these systems that I must interface with, know what a gift card number is. So, if you have these four interfaces and you have the common currency, you'll be able to bring Passbook guaranteed to your Ecosystem.

OK, what are some common currencies for you guys? So, we use gift card number. They might be club card number, an Event ID, and Event ID with the customer ID and an order number. There are a lot of things but just identify that shared piece of information that is probably a primary key somewhere in one of your databases.

So then six months later, when your boss is giving a presentation about how awesome your team is because we integrated with all these systems, you can say, "Yeah, but this is really what I did, four interfaces. OK, determining complexity. Now, stepping back from everything that we needed to do to bring this pass to Apple, I think we can impart an experiential wisdom of what it takes to determine the level of effort required to bringing a pass to your system. I've identified five facets that I think are really significant. First one is value, uniqueness, static versus dynamic, scale and systems integration. And on each of these facets is kind of a sub scale or scale within itself.

I'm using mountains of signs here. I don't know, do you guys snowboarder or ski? Thought it would something you guys do around here, no? No? a little bit of clapping out there. OK so, the greens, you guys know what those are? The greens are for people who kind of don't know what they're doing but still are courageous and want to be out there. And then hopefully at some point they transition to intermediate and intermediate is a little bit harder, you need some skill, you maybe took some classes.

And then you move to the blacks, the advanced category. The advanced is where you're kind of parsing through the snow and you know exactly what's going on. I see some nodding. So, there's a small scale. There's a scale within each one of these facets and we're going to review them.

Value, value as the value of your pass increases, the complexity is going to increase. So, when you start with a newspaper ad for instance, a newspaper coupon might be free because anybody can get to it. And I know it might have some value because with redemption it ends up adding value to you but we really don't care who's stealing that coupon.

Then a movie ticket, we move up to the movie ticket. It has more value. You don't want people just generating and stealing this left and right. You got to protect it a little bit. But at the same time if got stolen, t wouldn't be the end of the world.

And finally, you kind of have the gold vault of passes. I was imagining boarding passes would be in this. You really don't want people stealing them because they tend to have quite a bit of value and not only is the value in one of the passes. Not only is the value in all of the boarding passes that exist in Passbook.

But actually those services are protecting all boarding passes that exists very likely, right? They have access to systems that can see all boarding passes. So, it's supper important as you increase in value that you spend more time thinking about some of the web services and tricks we'll talk about later thinking about reliability, scalability and performance.

Uniqueness, a coupon can be used my multiple people, can be used multiple times. There's really no sense of counting. There's no sense of checking that much. You could almost put the value within the pass itself. So, that is much easier to do than let's say a membership card. A membership card might be used by a single household or a single family but it's used many times.

And your systems might in the backend be doing some really advanced statistics and processing on every use. But if you miss one use, if for some reason, you received an event and you couldn't actually serve all the data, it wouldn't be a big deal. And then there's the quantified use category.

The quantified use is all about taking score and counting every single use. A gift card is the perfect example of this. With a gift card, you actually decrement that value. You never want to over decrement or miss a transaction unless you want to give some things away for free. So, as it becomes less quantified it's going to be more complex. It's going to take a little bit more time to build that pass ecosystem. Static versus dynamic.

I don't know how many of guys have one of these. The little blue social security cards. They is nothing on it except a number and it looks really cheap. Well, it's just a piece of information and the pass can be a piece of information. And the simpler it is if it's just informational.

As you move up, maybe you're changing one state or one field in the pass, it might be an event and you're kind of remind somebody about an event and it's going to get a little bit more advanced. But for the multi-state pass where you're updating multiple pieces within the pass I thought a score board was a perfect representation of this. You're counting the number of innings, you're counting the number of balls or you're counting the score, all these are kind of dynamically updating as needed. The more states you have to update on your pass, the more time you need to spend. OK, scale.

Scale is about the number of passes that you have or the number of locations that you have or even the number or points of sales that you have. So, it could just be that you have a few passes. You're maybe a mom and pop shop and you're kind of in the center category where you have a few passes. Or maybe you're a chain so you have even more passes.

Or you're a huge enterprise and you have a ton of passes you have to worry everyday about reliability, scalability and performance. Another one I mentioned was the point of sales devices. Let's say you're in a department store and you're downstairs and you're buying shoes. And in the meantime you're spouse is upstairs, they're buying a shirt. If you're using that pass in both places you need to make sure that data is correct at the moment that pass is used.

OK, scale. You with me still? Systems integration, the last one on the complexity scale, the more systems you need to integrate with, the harder this is going to be. So, if you can re-imagine you're Ecosystem, if you can say, "I only need to support the iPhone or the iPod Touch" it's much easier to bring Passbook in, right? But if you have to support many electronic devices like the desktop when Sonal had to purchase on the web. You're going to have to think about a little bit more. You're going to have to make sure that you cover all your bases and you support those users hopefully as richly.

And then of course the most complicated one when you still have the physical gift cards to support, you have to make sure you keep those users in mind. OK, systems integration. That was the last facet. Don't assume, don't assume that complexity equals better because it doesn't. You guys can have great passes you can enrich the user's experience with the simplest of passes. We were in Passbook labs earlier and story after story, people are doing it. So, I encourage you. Create a pass. Figure out what you can do that enriches that user's experiences. OK, that was where my summary slide was. Web services tips and tricks.

OK, reviewing the pass asset sizes. This is the green category in which we're telling you if you're in the basic area, you should-- if you're in the basic, you should do these 4 things. So, review your pass asset sizes, adhere to if modified since, implement logging endpoints and expect dependency outages.

What does it mean to review your pass asset sizes? Performance and scalability is super important at Apple, often times before we have a launch we'll test and test and test until we know that our systems will stay up. And we were doing this in QA over and over and over and suddenly we were struggling, we were getting these slow, slow response time, it's taking forever to zip up our files. We looked a little deeper and we found out our asset sizes had changed. They went from 4 kilobytes to 280 kilobytes.

What!? Right? What!? So, we have publishers and they have the ability to change our assets on a dime. They decided they wanted print quality and on something that wasn't going to show them that quality. So, what I highly recommend you do, size your image assets, make sure that they don't exceed a limit and log them as necessary. Number 2, adhere to if modified sense.

This is an RFC 2616, it let's your clients make conditional requests. Basically, let's say there is this awesome WWDC exclusive party pass and if anybody was going to have it on my team, it'd be Alberto. He is the partier of our team and so he gets this great pass, and he last updated at noon. He's probably sitting here and thinking I've heard this presentation a thousand times.

He's looking at the back of the pass, right? And this pass shows all the parties that are happening and when, which hotel rooms and so forth. So, so he pulls it down. He hasn't updated since 12, that request comes over to our servers and on the servers, we look at that database and say for this pass, has there been any updates? Has there been any new parties added? And if there has been, scoop up all the contents, make that PK pass file, get it back to Alberto, and Alberto is like, "Yes, score, there's another party" right? And then five minutes pass, he flips that pass over and he pulls it down.

Request comes back to the server, I look at the database, and there's nothing new. Sorry, Alberto, I'm going to send you a 304-- I'm not going to spend any time building your PK pass file. I'm not going to waste your bandwidth. I'm just going to tell you, you have the latest. That's what adhere to if modified since and you can kind of see on this slide the request and then the response. At first you respond with a 200 and if it's not modified you return a 304. OK, implement logging endpoints.

Implementing the logging endpoints can sometimes be forgettable. Often times during our first shot at building these things is to get all the basics down, right? There are 5 endpoints and you'll do the first 4 and you'll get those knocked out. But I highly recommend that you make sure you've implemented the log.

What will this do for you? This will send you human-readable information about mistakes in your implementation. We spend so much time paying people to give us feedback, for example in these usability studies. We give them lots of money to know more information. But this is free feedback, so why wouldn't we use it? Implement the logging endpoint.

OK, number 4, expect dependency outages. If you have a service out there, what happens when that service goes down? Are you in good shape because you put a load balancer in front of it and you actually have 2, so it's no big deal if one goes down. If you can, try to put multiple instances of your web services out there. For us, we talk to something called Location Services. Location Services gives all the Apple Stores.

We ask location services when we generate a pass, "Hey, where are my 10 nearest Apple Stores? We then can cache that response locally so that every time the request comes in to build that pass, we don't have to check Location Services. And where this is super helpful is when Location Services goes down.

Did you need Location Services? Could you have survived with just putting in a long cache so that if Location Services goes down, it's not that big of a deal. It doesn't have to have a 100 percent uptime. And even better, I have shown this with the gray, if you can have a fullback file.

So, we could just have a fullback of all the locations that Apple had at the time of launch. At least we were able to serve the user with something, right? I mean how many of you want to hear I couldn't get my Apple Store Gift Card because they couldn't find the nearest stores, it's just ridiculous, right? So, passes should served with the bare minimum assets, even when dependencies are not responding. And set up default back up in data if you have to. Do your best to serve every request, but don't create unnecessary dependencies.

OK, tips in the intermediate category. Validating your origin. It's not sufficient to simply test, "Hey, is this pass valid from a data standpoint?" So, what I mean by that is for us, we have gift card and we could just for every request, simply test, "Hey, is this gift card number valid? Does it have value? But my recommendation is that you step back a little bit before even checking the contents of the pass, check who's the author.

Are you the origin? The last thing you want to be is a movie card generator or a gift card checker, right? If you check the signature before you even serve the request, you won't have people out there building or getting a valid gift cards. For instance, in our case, users might tweak requests they send.

They're tweaking each of those values to figure out the form of your system and understand it more. If you sign the pass first, if you sign the-- and I'm going to show you how to do this, the authentication token first, you're going to see that you can protect yourself a lot more.

OK, so how many of guys remember the authentication token? Do you guys remember this? A few of you, oh, that's like 10 percent, 15 percent. OK, authentication token. It's in the pass.json, and it actually comes over on 3 of these requests, register a device, unregister a device and get the latest version.

That means on all 3 of these request, if you know how to check your signature, you don't even have to serve any part of that request unless you know it came from you. How am I to do this? Try using HMAC, pick a message, any message, HMAC it, append it to the front, maybe sign or maybe add a few characters, some constants here and there, so you know how to recognize it.

And now, put that in your authentication token. HMAC is super easy to do. It's available on practically any language you're probably going to write a web service implementation in. Ruby has one. PHP, Python, Java, it's available in the that language or some third party library. Bouncy Castle is a good example of that.

OK, validate significant contents. Anyone can create a pass. With that said, the pass itself cannot be authoritative. In fact, even if they didn't create the pass and it just hasn't updated recently, you may not have the latest gift card value, right? So, make sure you check that source of truth. Go back and check gift card services or whatever your equivalent is, check it.

Number 3, leveraging caching, cache as much downstream information as possible. We talked about Location Services. We have the ability of caching Location Services. If for instance, a pass is also represented by associated product, cache that. Cache your image services, so if you use an image service, like Scene7.

Take those images and put them in local cache. Do not fetch them on every request. I highly recommend not to fetch them. You can even cache your encryption and decryption of your authentication token. And then the last one which I think is kind of interesting, consider caching the PK pass file.

Remember that WWDC exclusive party pass that I was telling you about? Well, if that's going around, guaranteed Stefan would have gotten it. Now, Stefan, he knows everyone and he's definitely going to share with iMessage his pass. So, he's going to say, "This is all the people I know." and forwards the WWDC party pass to all of his friends.

Now all of them are going to start requesting updates all at once. Now, if I was smart, and I cache the entire PK pass file, I could recognize based on the parameters of the URL that I just need to scoop up my PK pass file, and serve it. I didn't spend any time zipping that pass file up.

Cool, huh? OK. Four, in the intermediate category, monitoring. Be the first to know when your service is down. I hate it and hopefully it happens rarely, but I hate it when my boss comes in and says, "What's going on with this?" before I have noticed. If you can know that your pass, your web services have gone down first, it's a huge win.

There is so many monitoring systems out there, Site24x7. They allow you to send a request, a HTTP request, and you can configure everything. You can configure the post, you can configure the headers and then on the response, you can check that it is a 200 response? Is it the correct response type? So, monitor from external systems and then when systems go down, you're going to get a text. You might be out but you're the first person on it because you know it happened. Internal logging, this one is really easy, especially if you can add log aggregation like Splunk. But log things that matter whether it's a logging endpoints that came in.

The asset sizes we talked about when you start exceeding a level, log that. Another one, if your certificate is about to expire, you guys get one year, right? And sometimes we don't think about these things a year later, so start to log when you expire. And then when you hit a certain size or maybe get a daily digest of the logs, you get top 10 logs. This will help you monitor and keep your systems healthy without a lot of effort. Of course there's internal monitoring also, you can use Nagios to make sure those bits are up. But think about monitoring. Those were kind of the intermediate items.

Tips for the advanced, the first one I have is rate limiting. Rate limiting is all about making sure you don't unnecessarily serve the request that are coming in. So, if you have a denial of service attack, and you can identify, hey, this pattern of request is too fast. You can pull back, and you can just let them drop.

And your whole system can stay up and continue to serve valid requests without attempting to serve all these invalid requests. It protects you from a denial of service attack and a brute force attack. You can rate limit on a serial number, although be careful now that sharing is going to be prevalent.

You want to make sure it makes sense for your pass type. You can rate limit on an IP, be careful with that because probably a lot of people have passes in WWDC and the last thing you want to do is shutdown request coming from WWDC. But think about rate limiting.

Process asynchronously. When a request comes in, you want to serve that request as quickly as possible. The more time you spend doing downstream things and holding that connection, the less people you can serve, the more systems you have to have to serve all the incoming requests. So, if you go out and you try to pre-warm your caches, get all the information you can as soon as possible right even when your system starts up. So, for example like I said, gift cards can be associated with a product, and that's how when you're purchasing in the store, the strip looks very similar to the original gift card.

What I can do is I can go to product services as soon as I start up and I say, "Give me all the gift cards that are out there. And give me all the related strips that are out" then when the request comes in, I'm not wasting time getting those downstream items, I'm just pulling them from my local cache.

Logs. Writing to disk is expensive. If you allow every log that comes in especially on the endpoint to write to disk, you could be in a dangerous spot. So, if you throw it in memory and you have a write behind the disk, you're going to be able to serve that request a lot faster without impacting the rest of your systems.

Using a queue for push notifications and this is that callback update, so when you find out that the pass needs to be updated, instead of holding that connection for us from gift card services, we can just say, "Yeah, we got the request and we drop it in a queue." And then later on as soon our systems are ready, we just serve it to Push Notification Service. We don't have to wait to find out that Apple Push Notification service received the request. There's no need to, just drop it in a queue.

Avoid holding those connections, make it as short of a period as possible. OK, 3, leveraging auth token as storage. If you don't want to do this or you don't understand this, don't feel bad. This is super cool though, so pay attention. These impacts performance reliability but the basic concept is here.

On our request, Apple Store pass services needs to take the serial number I got from the pass and I need to crosscheck and get the gift card and the pin. Because remember the gift card is my common currency with gift card services, so I have to look at my database, and find the gift card and associated pin. That means before I can even check if the gift card has value, I've had to hit my database, and we know talking to a database can be slow.

So, one of the things you can do is embed your gift card and pin or your common currency or whatever information that's relevant to you inside your authentication token. OK, so how many of you guys remember authentication token now? Little bit more, OK. If you embed gift card, the gift card number and the pin in the authentication token, you actually don't have to ask your database what is associated with that serial number. You can go directly to the source of truth, your gift card services and say, "Hey, what's the value?" One less conversation with your database, pretty cool, right? So, take your authentication token and remember that message that I mentioned earlier, just pick a message.

Well, pick the gift card number, pick the pin. Pick something that's relevant to you. It could be a product number. It could be the URL for your image strip. If you're building different passes with different images, you can actually embed the image URL inside the authentication token, so you don't have to ask your database what image is associated with that pass. It's kind of cool. OK. So, I have some other things you can embed. Important dates like expiriees, your top 10 nearest location, once I've gotten the 10 nearest locations for a pass, I never check my Location Services again because I have it there.

Four, distinguish test and production. This actually happened to us. We're building in QA our test environment and Quality Assurance is helping us out and they're building pass after pass, every permutation you could imagine, and someone said, "what happens if we took these test passes to a store? They sure look real" and in fact, they are real because we signed them with our pass type identifier and the certificate we had. So, we had to rethink that. So, what you can do is take that pass type identifier that you embed in the pass.json and you can create a new pass identifier and test, and just have a different one for production.

Now, if you have a companion app, make sure your companion app can work with both-- it should be entitled to work with both of these, by maintaining a specific pass type identifier, it will make it so that if somebody walks into your store with a different pass with the test pass, your point of sale device or whatever you're using to redeem it can first check, "hey, do I recognize this pass type identifier" nicely say, "Hey, you're using a test pass. This is not going to work." Very easy way to distinguish between the two.

OK. Building in debug ability. If something goes wrong in prod, in fact when something goes wrong in production, how are you going to find out went wrong? This is a perfect example, I get a text from a friend of mine and they said, "Hey, I walked by the Apple Store and it didn't tell me that Apple Store was right there." So, I find out their serial number, and how do I really know what were the 10 locations embedded in their pass? Well, if you planned for it, you can make it so that your web services takes a certain parameter, debug for example.

And then on your web services, when you're building of that pass, you can say, "Oh, I need to add extra things, and I need to add it to the back of the pass." So, on the back of the pass, I can begin to add 10 nearest locations. I can add what data center I created and I can add the host name it was created on.

Then when I receive that pass, I can turn it over and I can say, "Hey, call my friend up." Actually, I don't know that you tagged the pass" or "did you know you tagged the pass while you were in Paris?" And of course you're not going to see the 10 nearest locations while you're in Seattle. With iBeacon this is going to become a lot easier by the way. OK, and then also have a test serial number for production. This is great for using with the monitoring.

So, that was the last of the tips and tricks, we had kind of the easy, the intermediate, and the advanced. Today, we talked about Apple Store gift card, we pulled that curtain back a little bit for you, showed you what we did, why we did it, leveraging existing systems, 4 interfaces, right, obtaining the pass, your source of truth, redeeming the pass and the callback update.

Determining complexity, we went through some facets that allowed you to measure the level of effort. Basically, you can go back to your bosses and say, "Hey, I thought about this. I've looked at the Ecosystem. I know the facets that I need to think about and we can do it too. We can have a pass too." And then some web services tips and tricks, those are all online. You can go back through them. Read them, understand them more.

Paul Marcos, he does a lot of this for you. He helps us prepare. He's our evangelist, he has great information, so if you have any questions, contact him. There's documentation online. In addition, if you missed it earlier on the What's New in Passbook, it's recorded. So, check that out. I want to call out Harnessing iOS to Create Magic in Your Apps specifically.

This session as well as the next session and especially the next session is again about using standard iOS technologies, kind of as an external developer, but using those technologies to enrich the users' experiences. So, they do some really basic easy things, but it just changes the life of your apps from an external standpoint. Thank you so much for joining us. [Applause]