Write clear purpose strings

Hello, App Store developers. I'm Greg from the App Store Review team. Today I'm going to share tips from our team to help you write clear, succinct purpose strings.

At Apple, we believe that privacy is a fundamental human right, and so 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 user privacy in the Apple ecosystem, like minimizing the data you collect to just what you need. Today we're going to focus on one requirement we see both new and experienced developers struggle with: being clear and transparent when requesting permission to access protected resources. We'll share tips and examples to help you prevent a common 5.1.1 rejection: insufficient purpose strings. We'll start by giving some background on permission requests and the role they play in protecting user privacy. We'll then focus in on purpose strings, short descriptions provided by you to describe why your app needs access, and talk about some things App Store Review looks for in review. We'll then finish with examples of purpose strings that wouldn't pass review and discuss how they can be rewritten to be clear and specific. But first, let's talk about permission requests. Our devices are an important part of our lives. What people share from their devices should be up to them, which is why all Apple operating systems restrict access to protected data and resources by default.

To access this information, apps must first request the user's permission. This puts users in control -- they can decide which apps have access to what. But to make an informed decision, people need to know more about why your app needs access and what it will do once it has it. This is where purpose strings -- also called "usage descriptions," -- come in. A purpose string is a short message you provide that appears on every permission request. It describes why your app needs access and what you will do with the user's data. You'll define these messages on an app's information property list -- or info p-list -- by setting a string value to a resource-specific key. This is an important interaction between you and your app's users on Apple operating systems. It's a chance to build trust by being clear and specific about what your app is trying to do. Why is this so important? Let's compare these permission requests from apps with a situation from the real world; one that you've probably experienced before. Imagine you go to buy a cup of coffee from a local coffee shop. Coffee in hand, you're ready to pay when the cashier asks for your phone number. Huh. They haven't asked for that before, so why would they need it? This can go one of two ways. The cashier could say, "We use your number to provide a better coffee-drinking experience." So that sounds great, but it's not very specific and it's not clear what that means. On the other hand, they could tell you how they use your number to track your purchases, rewarding you with a free cup of coffee for every fifth cup you buy. In both cases, it's up to you what happens next, only in the second example do you have the information you need to make an informed decision. This kind of positive user experience is what App Store Review looks for when reviewing purpose strings. We make sure the purpose string gives users the information they need to make an informed decision. What does this look like when we review your app? Well, we approach apps like a new user would. This means we see permission request alerts just as your users will when we try to use features that access protected resources. This way we understand the full experience and can anticipate what people need to know to make informed decisions. So in review, we look for two key qualities in purpose strings. They should explain specifically how the app will use the data and provide an example of how the data will be used.

Let's take a look at some examples to see what purpose strings look like when they have these two qualities and what it's like for users when they don't. First, we have a navigation app that specializes in recommending scenic routes. When users try to access the navigation feature, this is what they see: "To use location." Not much to go on, right? When you're developing an app, you know exactly what you will use a resource for. But users don't have the same understanding about how your app works. They rely on the information you provide in the purpose string to make their decision, and in this case, the user doesn't have the information they need. To build trust, this developer needs to say specifically how they plan to use the data and provide an example. This would be better. "Your location is used to determine the recommended route to your destination and provide turn-by-turn directions." Now the purpose string is specific and provides concrete examples of what the app will be able to do with the user's location data. Keep in mind, if your app supports localizations for a global audience, be sure to provide localized purpose strings as well. We recommend testing your app set to different localizations to confirm the user sees the correct localized app content. Well, let's take a look at another example. Here we have a social network app. The developer shares data collected in the app with third parties to deliver targeted advertisements. Before collecting any data used to track though, they need to request permission using App Tracking Transparency. When you first open the app, the App Tracking Transparency permission request appears. Here's what it currently says: "Your data will be used to provide a better experience." So this may be true, but it doesn't tell the user what they need to know. How, specifically, will their data be used? What's an example of the better experience they should expect if they grant permission? A better approach would be: "Your data will be used to deliver personalized advertising for products that are most relevant to you." Now it's clear what the developer will do with this information and what the user would gain from granting access. This developer could even provide more context about what would happen if the user says no to tracking. "Your data will be used to deliver personalized advertising. You will still see advertisements if you decline tracking, but they may be less relevant to you." Either of these examples would be fitting for this app. The goal is to be transparent and clear at the moment you request permission. Another thing to keep in mind; many apps on the App Store integrate third-party SDKs and libraries. These SDKs and libraries can provide a wide variety of features and services, such as account authentication. What you may not realize is they can also reference APIs that will try to access protected resources, like location data. If your app has a reason to access these resources, define a purpose string on the info p-list that applies to your app's specific use case. If not, you should remove references to these APIs from your app's binary. Remember, you are responsible for everything in your app, including SDKs, libraries, or other code from third parties. When developing your app, be sure to familiarize yourself with any protected resources they may try to access and ensure that these requests are intentional before submitting your app for review.

So you might have noticed the examples so far have focused on purpose strings with too little information. But what about the opposite? Is there such a thing as too much information? Let's see what this could look like. Here we have an app for local gardeners where you can look at pictures of your friends' gardens. When we go to take our first picture, however, we see the developer chose to include a long description on the request. Let me see if I can do this in one breath. "Whether you're just discovering your green thumb or a veteran plant expert, use our app to share your love of gardening! With access to your camera, you'll be able to take profile pictures posing with your favorite succulent, capture your raised beds in their best afternoon light, and much, much more!" A bit much, isn't it? Usually just a sentence or two is enough to tell people what they need to know. For our garden app, this would be better: "Our app uses the camera to capture photos for updating and sharing on your gardener profile." Now the purpose string is specific and includes examples that cover the various uses of the camera in the app. Not too long, not too short, purpose strings should be just right. Longer, wordier purpose strings can be accurate and may pass review, but they're not the ideal experience for the user. Keep the description straightforward and to the point so it's easy to read and understand when viewed in the app. Let's put all of that together and go on a quick permission request journey with one of our hypothetical apps. Accurately and concisely explaining to the user why your app needs access to sensitive data lets the user make an informed decision and improves the chances that they'll grant access, so that your app will function for them exactly as you've intended. It allows you to describe your app's unique experience while keeping the user in control of their personal information. And understanding that users will make their decision to grant access based on what you write will help you add the appropriate context to your purpose strings to keep them relevant, transparent, and informative.

Keep these examples in mind for your future submissions to the App Store. We hope they help you keep users informed and allow them to enjoy everything your app has to offer. Thanks for watching our video. To learn more about permission requests and developing with privacy in mind, there's helpful guides and documentation on the Apple Developer website and in the Human Interface Guidelines. We look forward to reviewing your future submissions to the App Store.