Hi everybody. I'm Chris Espinosa from Apple. We're going to have a lot of fun today. We're talking about kids and apps. Going to cover a few things, going to talk about the history of Apple and kids, how we got where we are. Some recent regulatory activity worldwide and in the U.S. that's going to affect you if you're vending apps that are addressed to kids; some new programs we've had in the last year for Apple IDs for kids under 13, both the Student Apple ID program and Family Sharing that was introduced on Monday; talk about your responsibilities if you're selling apps that are directed at kids; some best practices for doing that; and then a brief view about what to do about other countries.

But first of all a little history: Apple and kids go way back. I personally know this, because I was a kid when I started working at Apple on the Apple II in 1977. One of our first programs was called Kids Can't Wait. We've been getting computers in front of kids for almost 40 years, from the Apple II through the iMac.

We had a huge influx of kids into the ecosystem with the iPod, the most popular music playback device in the history of man. And now we've got a huge number of kids both in homes and in the schools using our mobile devices. Now, it was great when we started out, because it was a fairly simple model. Parents would buy a device that was pretty expensive.

They would buy some software at a store. They would put it on their device, and their kids would use it in their home or classroom, and that was pretty easy and it was pretty safe, but it's a different world now. It's different for kids, and it's different for parents, too. Kids are beset by a world on the Internet where there are millions of strangers out there they can have instantaneous contact with, both other kids and grownups.

And there's also billions of dollars of marketing and merchandising that are aimed at those kids, and that's why around the world people are working on legislation to protect kids. Now, we've been doing some things gradually through OS X and through iOS to give parents and kids some protection in the use of technology.

The parental controls that have been in OS X forever and the restrictions on iOS will really help parents configure the device to work the way they want it to work with their kids, and as app developers you're kind of accustomed to this. Sometimes, as in the previous session, when you go to use a restricted data class, it just won't be available, because there's been a parental control set on that device. So, you're accustomed to dealing with that as app developers.

And then when we start putting networked capabilities in the hands of users, we're making some accommodations to do things that are specifically directed for kids, Game Center for example. We knew that a lot of kids would be using Game Center on their parent's devices, and so we let them have their own handles regardless of their age. They're more or less anonymous. We don't collect personal information.

We don't allow chat for Game Center handles for kids under 13. There is no ads. It's generic screen names. There's no image sharing. The chat messages they can use are canned messages only, not free-form chat. So, we've created some, you know, little cul-de-sacs of functionality for kids under 13.

There is a new kid's category in the App Store that you may have heard about. You can go in the App Store guidelines or go to the App Store sessions or labs and learn a little bit more about these. If you're targeting your apps to sell to the parents of young kids who are going to use them, there's a couple of things you need to do to get into that category.

You have to have a privacy policy on your page, and you've got to link to that privacy policy on your app page. You cannot have behavioral-oriented advertising. You can have contextual advertising, but not behavioral-oriented advertising that tracks your kid. You can do no tracking across sites or across apps.

The contextual ads must be appropriate for kids, and you've got to have a parental gate on your app before you get out of the app to go to In-App Purchases back to the App Store or to any online site. So again, little cul-de-sacs of functionality to accommodate kids using our technology.

But there is a lot going on in the world and a lot going on in the United States about what technology companies, Internet companies in general have to do about kids to give parents the safety and control they want. Generally it's about being sensitive to the needs of parents and kids.

But, some areas that we've gotten scrutiny and you may have gotten scrutiny, including not being clear about the total cost of an app. A free app that may cost hundreds of dollars in In-App Purchases in order to have a good play experience is going to be considered a little out of line. You may need to look at that. Aggressive exhortations to buy, where you are constantly bombarded with the urge to spend money, that's not going to be OK for some of the regulatory agencies, and you may have to be careful about some of these.

You're responsible for local law compliance. There are some principles that you can follow. The British government has put some together. There's a link on this website. You can go back to the tape and read it. There's some general principles about dealing with kids in websites and in apps that are really, really good to follow.

Now, at this point I want to go off script a little bit. I want you on a lot of these slides to be thinking I'm going to call my lawyer, OK? So, we're going to take a practice right now. I want you to just think to yourself, I want to call my lawyer, one, two, three.

The way the law was originally written was that you couldn't collect the first or last name, the email address or phone number, any physical address, street name or the name of a city or a town, Social Security, user identifier, any screen name that would have a way of contacting the kid, or information that combines with any of those above.

And it defined an acceptable mechanism to get parental consent. Well, last year in 2013, the Federal Trade Commission in the United States revised that act to clarify it, expand it a little bit, and these are the things you'll really need to careful about. They clarified that everything that applied to websites in 2000 applies to mobile, too. So, all of your apps are affected. They expanded the definition of personal information that requires parental consent according the new capabilities of mobile devices.

So, any photo or video or sound recording that your app makes that could include the child's own image is subject to the COPPA regulations, OK, very important for you to know that. Geolocation that can isolate the kid's location to a city or town - subject to COPPA regulations, any screen name or identifier that can be used for contact, that's pretty much the same, or a persistent identifier that identifies them across sites or services. If you're using this information solely within your app and solely for internal functionality to your app, that's OK.

But, if it goes up on a website, if it goes outside your app, if you're using it for purposes other than just making your app work, then you're subject to the requirements of the Children's Online Privacy Protection Act. And there are some requirements of that, and we're going to go into that later.

Now, kids under 13 who are subject to the COPPA law have Apple IDs. They have it in two ways. The first is an Apple ID for Students Program, and this is what we rolled out last year. It's a program that gets verified parental consent through the COPPA law through schools, OK. We've rolled it out in several large school districts starting last year and going into this year, and they're full-fledged Apple IDs for iCloud and iTunes. They're not these Game Center accounts. They're not kid accounts. They're not junior accounts. They really are full accounts, OK.

There are a couple of little things we've applied to them. Students do not receive marketing materials from Apple. That box is implicitly checked to not receive marketing materials, and the Limit Ad Tracking switch is automatically set for accounts for kids under 13. Now, this is really only for, you know, a few tens of thousands of kids now. And of course, we're going to expand that in more school districts. But, what we announced Monday is much bigger, and that's Family Sharing.

Family Sharing is a method to get verifiable parental consent under the COPPA law for any family in the U.S., and in fact, we're using the same mechanism worldwide for parents to create Apple IDs for young kids. It integrates with the Ask To Buy feature that you saw on Monday, so that parents can see and approve of purchases by their kids.

Once again, just like the student IDs, they're full-fledged Apple IDs for iCloud and iTunes. The same switches are set, no marketing and no ad tracking, and the verified parental consent is set up by a special mechanism. So it's a way for us to get the parents to create accounts for kids under 13 and then bring them into the family, let them share existing purchases and make new purchases.

Let me walk you a little bit through how the whole Family Sharing program works because that'll give you a good background for it. You start with the person who has a payment method and an Apple ID who decides to be a family organizer. And the family organizer can add or invite other existing accounts into the family and share their payment method and share their existing purchases with them. They can also create new accounts for kids under 13 and create a family circle. That can be up to six accounts total.

And the requirement is that during the life of the family all the accounts have to use the family organizer's payment method or credit card, OK. The way Purchase Sharing works is that you have this bucket of purchases that you've made, and that is made available to everybody in your family. They can see all of your movies, books and apps that - and songs that you have purchased.

They can pick one out of your purchases and re-download it to their device as if it was in their purchase history. It's not their title now. It doesn't show up in their purchase history. It's still yours, and then if you leave the family, they lose the rights to that title.

And then the Ask To Buy capability is really cool. If one of your family members has the Ask To Buy switch turned on and is shopping in any of the stores and wants to purchase something, at time of purchase request a notification is sent to the organizer and other parents in the family saying that this person wants to buy this product with a link to the product page. And the organizer and the parents or guardians get the option to approve or deny that request.

And on approval, they complete that purchase. Now, this is going to affect the way your In-App Purchases work, because there may be a long time between the time when the user taps the In-App Purchase Buy button and when the parent actually sees it, taps OK, the request comes back and they get to buy that.

Go back and look at James Wilson's "Optimizing StoreKit Transaction" session. There was one given yesterday and he's reprising it tomorrow morning. See that. He's got some great tips for how to deal with that in your app. So, given all of that, what does this mean to you? What does regulatory environment mean to you? What do the new under 13 accounts mean to you? What is Ask To Buy and Family Sharing mean to you? And at this time I want you to say-

If you've got a general-purpose app like a word processor or a to-do list reminder, you're not targeted at kids, you're not in the kids section of the store, you don't ask their age anywhere - you're probably OK under the COPPA law, which only affects things that are directed at or you have actual knowledge of the user's age.

Again, you have to consult your lawyer in order to know whether you do or do not follow- fall under the law. But, typically, if you have a general-purpose app, you don't market to kids, you're not in the kids section, you don't know the age, then you don't have to worry about COPPA conformance specifically.

But, if your app is directed at kids, which it probably is if you're in this room, you have some implementation choices to either avoid requirements for conformance with COPPA or to conform with the COPPA law. And there three basic approaches, and I'm going to walk you through them now.

You can either avoid doing the things that subject you to COPPA regulation. Just stay out of it. Do not collect personally identifying information - it's a great alternative. Or you can choose to collect the information of how old the user is and present a forked experience, different experiences for kids over 13 and under 13, disable the personally identifying information experience for the kids under 13. That's a viable choice. That's a good choice for you to make.

Or, you can, if you're all about that information, if you're all about video, if you're all about chat, if you're all about sharing stuff, you really need to address kids under 13 with the full features of your application, then you have to get verifiable parental consent of the use - from the user's parents before you can proceed with the app, and we'll lead you through some steps to do that.

So, let's look at the first alternative, avoid it. This is pretty easy for most apps. Don't collect personally identifying information. Don't show behaviorally targeted ads, although contextual ads are fine. Don't support photos. Don't support voice recording. Don't support social networking. Don't support finding your location. Don't support your own push notifications or any other COPPA-regulated functionality. You can go a long way actually without doing those if that's what your app is about, if it's a simple game or a general purpose application.

Ask To Buy does not make you COPPA compliant. Getting the parental permission to purchase and download the game is not COPPA compliant parental notification and consent to collect personally identifying information. So, just because the kid bought your game through Ask To Buy, that doesn't let you off the hook.

If you limit yourself to what Game Center does, you're generally good, but you got to check your app and make sure that you're not doing any of these things. If you saw the previous presentation, then you know that there are some protected data classes in both platforms, iOS and OS X.

If you look at those protected data classes, this gives you a really good idea of whether you're going to be generally compliant with COPPA or not. If you're using location or contacts or photos or microphone or the worldwide or the camera or social or HealthKit, you are subject to COPPA regulations, and you need to be careful about that. Even Bluetooth, because Bluetooth has a persistent identifier that can be tracked across devices and across locales, and so even use of Bluetooth makes you subject to COPPA. So, let me show you some demos of some applications that are PII-free.

This one is called "Bonsai Slice." It's a game where you swack things with swords. Again, you start it up. There's not much to do except tap to begin. There's no particular login or identification of yourself or any setup, and you can just go right into playing the game.

So, there we go. I think that's enough game demo for that. So, that is the first approach, which is just don't do it and you'll be fine. So, if you've got a general purpose app or you've got a kid oriented app that doesn't collect any personally identifying information, you're fine. You're in the clear.

The second approach is to have an age screen so you can tell whether your user is under 13. And then if they're over 13 you can collect PII, and if they're under 13 you just turn off those features, OK. It's pretty straightforward to do. One of the interesting things is, well, isn't their age personally identifying information? And the answer is no. That's not. You can ask their age, and you can record their age so you don't have to ask every time. If fact, we recommend that what you do is you ask on first launch. You record the age in per account iCloud preferences store.

And so when that user is logged into iCloud, because your under-13 users are all going to be iCloud users. Anytime your app launches and you read that recorded age of over or under 13 from their per app iCloud preferences, you know whether this user's under 13 or not, and you don't have to ask again, and you can continue to tailor the preference - continue to tailor the experience for that under-13 user. If they're under 13, you can't just exit. That's not appropriate. That is, have an app that people can buy or download and then have them input their age and then tell them, oh you're too young. Your app will be rejected from the store if you do that.

If you have an age gate and you have different behaviors for above and under 13, you have to have a pretty unified valuable experience for under 13. You can't just quit, and you can't have a really, really crippled version of the app. It's got to be useful. It's got to be fun. But, you can omit certain features like, you know, like chat. You can have chat in the over 13 and not have chat in the under 13 as part of your gameplay, for example. Once again, you should be thinking one, two, three.

This is "Toca Town," another great immersive environment for kids. You can tell from the start that this is targeted at kids, and it's likely to have kids under 13. So, it's the kind of thing that would be subject. And it's got a parental age screen. If you see the For Parents way up here in the corner, when you tap that they ask you with a very simple challenge what year were you born in.

And that's - this is asking you for both under or over 13 or also for parental information. If you enter a date that is old enough to be a parent then you can go to the license agreement. You can go to additional purchases. You can go to off app websites. This is the kind of thing that is required to be in the App Store in the kids section.

And finally here's "Fraggle Rock" from Jim Henson. This is just another mechanism that you can use to ask the kid's age. You start up, there's info. It's the same kind of thing. This is parental info, yet they're asking for the full parental - full age information here, month, day, year. So, you can have a just the year.

You can have it just the age, or you can have a full birthdate. Any one of those input methods is sufficient to ask whether the kid is over or under 13. Now, remember that that is only for verifying whether you can collect PII or cannot collect PII. Knowing the, knowing that a parent has - knowing that the age is sufficiently old enough to be a parent is really not enough for verified parental consent. That's our third category.

You can - instead of having an application that doesn't apply or having an application where you have forked behaviors, you can have an application that always uses the camera, always uses the microphone, always uses chat and social networking, uses location services, goes the whole way. You can do that for kids of all ages if you have verified parental consent. And that turns out to be kind of hard to do, because parents have to consent explicitly for your app.

Parental consent that Apple has received for the kids to use the device, we cannot delegate that to you, because we don't know what your app is doing. You must ask the parent to have an explicit consent to use that app for that kit, and that's a lot of work on your part. It's the same rule, you know if you've got a website, if you've been dealing with this under the - since 2000 on a website, it's the same rules.

So, it's pretty easy if you've already got a website. In fact, many apps just simply direct the kids to the website to go through the COPPA process before they can proceed. There are several ways to do this. You can pick the one that's right for you, talk to your lawyer about it. And a simple parental gate of the kind that you need to be in app - kids section of the App Store, that is not sufficient for COPPA verifiable parental consent.

Once you get verifiable, verified parental consent, it's not over. Some of the requirements of collecting PII are that you have to display that PII and allow parents to review it and delete it on demand. You, the parents need to be able to stop the collection going forward. You have to keep that information reasonably secure and be able to demonstrate to the FTC that you are keeping it secure, and you need to delete the information when you no longer need it. You can't amass vast databases of private information about kids.

Now I don't have a lot of good examples of what on-device verified parental consent is mainly because this is kind of new, and not a lot of apps are doing this. The traditional way of doing it, if you just look at a website like Neopets, this is the traditional way of getting verified parental consent is a webpage with a lot of legal contract and then a form that you print.

Please print legibly, and then you fax it in to the company. This is what websites traditionally do before you create an account. And in the app world, for example, there is the great family app called "Life360," which is a great way for parents to communicate with their kids. It sets up chat. It sets up location services.

It is a fully featured family management app, and it's going to have kids under 13, and what they do is you - they send you to the app to create accounts, and they send you to the website to create accounts. And the website just has a PDF that you fill in, you sign and you mail or fax in to the company, because that's the state of the art.

We can do better than this, and we want to do better than this. We really want to give parents a great way of delivering verifiable parental consent in a way that's acceptable to the Federal Trade Commission. Here's an example of a good start at it. Here's an app called "DIY." When you start it takes you through some setup screens of what it does.

You pick an avatar, and then it has an age slider, and this is kind of like the age slider that you saw in the previous category for deciding whether to turn on or turn off capabilities. And notice that if I'm 14, and I pick a nickname, and then I can enter my email and password to create an account. Very straightforward.

But, if I set an age under 13, notice that interfaces change. It doesn't ask me for my password and email. It asks for my parents' email, and it sends my parents an invitation that they must approve before I can go further with an account, and that does the email, that does the parental consent process. They have to review the agreement. They have to sign it. They have to send it in. That's what you need to do under the COPPA law in order to do that.

So, those are the ways that you can get verified parental consent. Now this applies primarily in the United States of America and the territories that are subject to the COPPA law. That is not your whole market. And the good news is that in most of the rest of the world there aren't laws like COPPA.

But, they're coming, and many of them will be modeled on the U.S. law. And the implementation method we've chosen, which is probably a good idea for you to follow, is what we're doing in the U.S. we're going to deploy everywhere because it shows respect for kids. It shows restraint on our parts, and it makes us adaptable and flexible for whatever other countries may adopt.

The most important thing for you is that the ages I've been talking about, 13 to be a kid, and 18 to be able to sign a legal contract - don't take those as hard coded values, because they're different worldwide. The age that COPPA applies to in the United States is 13.

But other countries have ages where - children's private information is protected, and that varies all around the world from 13 up to 16 years of age. Similarly the age at which you can agree to a legal contract is 18, but in other countries it may be 19, 20 or 21. You should tailor these on a per country basis.

Instead of hard coding 13 or 18, you can check your region at runtime using StoreKit, just use the ProductsResponse to a products request with your bundle identifier, get the products response and look at the priceLocale field. And that will tell you the locale of the store from which your product was bought. And then if there are regulations that apply in that locale, you can make decisions on what age is based on that locale rather than hard coding the numbers 13 or 18. OK, I wonder what you're thinking now. Hmm, maybe it might be -

They are going - this is really, really going to increase the use of our devices among kids. We want to make sure that that's safe and that's legal. If you're writing apps for kids you should apply to all applicable statutes in all of the areas where you sell your apps, and that means you need a lawyer.

Don't collect personal information, ID, pictures, sounds or locations at all if you can avoid it, and then you'll avoid a lot of hassle. If that's what your app is about, then you can choose either to have a forked experience based on asking the kid's age, and at that point you might as well fork for younger kids, older kids and parents in order to be in the app store. That's a really, really good idea. Or if you really need kids under 13 and you need personally identifiable information, then what you need to do is go the FTC codified verifiable parental consent process.

Get the parent's signature on a piece of paper before you can allow the kid, before you can allow your app to collect personally identifying information from the kid. Do the same thing worldwide - it'll be a lot more convenient and it'll be a lot more consistent and prepare you for what's going to happen in the future.

Here's some resources that you can deal with. There's a Safe Harbor Program, where there are organizations that you can go to, to let them help you set up accounts for kids. Federal Trade Commission has a whole list of these safe harbor organizations. It's a really, really good place to go to talk to people, consult with them and use some of their services to be safe for kids. Another good organization is Moms with Apps. Moms with Apps has a lot of expertise in this area. And you can go to the Moms with Apps websites to see some of examples of apps that deal with kids in a really, really great manner.

There's always our Technology Evangelist Paul Danbold, and developer forums, lots of developer forums on apps for kids. Related sessions, since it's late in the week, there aren't too many coming up. The session right before this on Security and Privacy is a really good one to go back to the films on.

Also to the "Designing a Great In-App Purchase Experience" that Rachel Roth gave. That is a heck of a presentation. You ought to go to the tape and see that. And then "Optimizing In-App Purchases," that's the one I mentioned with James Wilson telling you how to handle the scenario where a kid asks for an In-App Purchase, asks to buy his own, and their parent is going to be two hours before they click the switch and let the kid get those coins that they needed in the game.

I really appreciate you being here today. I hope you develop great apps for kids. We want to have a lot of apps for kids available for Family Sharing when Family Sharing opens up, when iOS 8 and OS X Yosemite are available. And I really look forward to seeing you in the store. Thank you very much everybody.