Do more with less data

Hello, App Store developers. I'm Greg from the App Store Review team. Today we're going to share some best practices for creating great apps that do more for users while collecting less of their data. At Apple, we believe that privacy is a fundamental human right and Apple products are designed to protect privacy and give users control over their information. In addition to designing our products with privacy protections, privacy is central in the App Store Review Guidelines. Guideline 5.1.1 in particular details some requirements that are essential for protecting users' information in the Apple ecosystem. Improving your app's privacy practices won't only help you prevent issues in review, though. Users prefer apps that respect their privacy. So today we're going to share three tips that will help you build great apps that put users in control of their data. Our first tip: where possible, delay sign-in flows or remove them altogether. Next, limit the data your app requests to only what is necessary. And last, be ready with an alternative when users decline to share their data. Along the way, we'll share concrete examples that'll help you get started. So let's start with signing in. Wherever possible, let users enjoy your app without it. People prefer to go without accounts where possible. They want to get to the action quickly, and forcing people to sign in before they can do anything useful can be discouraging. To keep users engaged, let them explore your app. Don't include a login if there's no need for an account or delay the login until the app's account-based features come into play. For example, a sporting goods app might allow the public to freely browse their products until a user wants to purchase an item. This allows users to enjoy the app without sharing personal data until there's a specific need for it. Our second tip is limit the data you request to just what your app needs. Data minimization is a pillar of Apple's approach to privacy, and we encourage app developers like you to adopt it as well. Ask yourself, what features do I want to deliver to my app's users? And then, what's the minimum amount of data I need to make this feature great? By asking yourself these questions early in your development process, you won't end up asking users for data you don't need. Let's see what this can look like for users in registration flows when apps try to access a protected resource. In registration flows, we talked about when it makes sense to ask new users to register. Next, consider what data you ask for in the registration flow. Information you request should be essential for your app to function, or else, required by law. So let's look at an app that's asking for more than they need. Here we have a registration page for a shopping app. Looks like all fields are required. Requiring the address makes sense since they'll need it to send me my orders, but why would they need to know my birthday or whether I'm married or not? Well, it turns out this app has a feature that sends coupons to users on their birthday. While the coupons might be a nice perk, people can still enjoy the main shopping functionality without the app knowing when they were born. But there are no features tied to marital status, so that should be removed altogether. And since knowing a user's date of birth isn't essential for the app to function, it shouldn't require all new users to provide it. Instead, this should be a clearly labeled optional field. Including a brief, transparent description of how the birth date will be used will also help people make an informed choice. Similarly, be careful when requesting sensitive personal data like health and financial information or national ID numbers. Only relevant app types with a critical or legal need for this information, like medical or banking apps, should ask for it with a clear explanation of how the data will be used and stored. After reviewing your app's needs, you might find that your app actually doesn't need much data from users to authenticate their account. In that case, instead of a long registration process, consider offering Sign in with Apple as a privacy-focused alternative. With Sign in with Apple, users spend less time filling out forms or registering emails and can quickly start enjoying what your app has to offer. In addition to registration, many apps use device resources which are protected by default on Apple operating systems. This means if you want to do things like use the microphone, communicate with Bluetooth devices, or use location services, you'll need to ask for the user's permission first. Our recommendation here is the same: only ask for what you need. This advice applies to all protected resources on Apple devices. Here are some more examples. Many apps offer an option to select a photo for a profile page. But if this is your app's only use for Photos, you don't need to request access to every photo the user has ever taken. Instead, a better fit for your app's needs is photo picker, so users can quickly select the perfect photo for their profile without providing more access than is required. Photo picker can also be configured for selecting multiple photos or capturing photos and video.

You may have a chat messaging app and are thinking about requesting access to Contacts to help people connect with their friends. We have another idea for you. Similar to photo picker, you can configure a view controller for selecting contacts, letting users select the one or more contacts they'd like to connect with. For some apps, only a few features rely on location data. Rather than prompting the location permission request at launch, consider adding a Share Current Location button right in your app's experience. When people tap the button, your app will receive access to their location for that session, just like Allow Once, and will last until they leave the app. This gives people a low-commitment option when they use your app. Like other protected resources, data in the Health app can be accessed with the user's permission through HealthKit. The Health app contains sensitive, personal information and your app should have an appropriate reason for trying to access this data. If your app doesn't have any health or fitness features that would require this data, make sure your app doesn't include the HealthKit framework or any references to it. Otherwise, your app may not pass review. And don't forget most permission requests include a purpose string. Purpose strings are short messages provided by you in your app's info p-list describing how your app will use the requested data. Writing clear purpose strings helps users make informed decisions. For more tips on writing purpose strings, check out the links associated with this video.

The main takeaway here is to think critically about what data your app really needs and, wherever you can, build apps that require less. This leads us to our third tip: get creative with alternatives that still provide great experiences when users decline to share their data. People expect apps to still function when they decide not to share their data. Apps that don't create a poor user experience and may not pass review. Anticipate that some users will decline to have their data collected. Others may be using devices with parental controls activated or other restricted privacy settings limiting access to certain resources; be ready with an alternative. If someone prefers not to share their location data, let them manually input an address or postal code instead. When people would rather not take a photo of themselves, some apps let users customize an avatar, giving their profiles a personalized touch without sharing more data than they need to. Also, keep in mind, if the user decides to not grant permission to access a protected resource, it's important to respect their decision. Don't include messages in your app asking them to change their mind. If they try to use a feature that requires access to a protected resource, though, it can be appropriate to include a message letting them know they can change their permission choices in the Settings app. Those are our tips for doing more with less data. Incorporating these practices early in your development process will not only help you avoid delays in review, your users will appreciate the steps you've taken to respect their privacy. We think these privacy best practices will help your app collect less while delivering a satisfying, feature-rich experience.

Thanks for watching our video. If you're interested in learning more about Apple's approach to privacy and other best practices, check out the other videos on the Apple Developer website and app.