app store

Accessing User Data and Resources

User privacy is paramount. To help people trust your app, it’s crucial to be transparent about the privacy-related data and resources you require and how you use them. For example, you must request permission to access:

  • Personal data, including location, health, financial, contact, and other personally identifying information
  • User-generated content like emails, messages, calendar data, contacts, gameplay information, Apple Music activity, HomeKit data, and audio, video, and photo content
  • Protected resources like Bluetooth peripherals, home automation features, Wi-Fi connections, and local networks
  • Device capabilities like camera and microphone

IMPORTANTBeginning in iOS 14.5 and iPadOS 14.5, you must use the AppTrackingTransparency framework to request the user’s permission if you want to track them or access their device’s advertising identifier. To learn more, see User Privacy and Data Use.

When you submit a new or updated app, you must provide details about your privacy practices and the privacy-relevant data you collect so the App Store can display the information on your product page. (You can manage this information at any time in App Store Connect.) People use the privacy details on your product page to make an informed decision before they download your app. To learn more, see App privacy details on the App Store.

Screenshot of the App Privacy screen in an app’s App Store product page. The top card in the screen is titled ’Data Used to Track You’ and lists contact info, location, and identifiers. The bottom card is titled ’Data Linked to You’ and lists financial and contact info, location, purchases, identifiers, and browsing history.

An app’s App Store product page helps people understand the app’s privacy practices before they download it.

Requesting Access Permission

Before you can use user data or protected resources, you must get people’s permission to do so.

Request permission only when your app clearly needs access to the data or resource. It’s natural for people to be suspicious of a request for personal information or access to a device capability, especially if there’s no obvious need for it. Ideally, wait to request permission until people actually use an app feature that requires access. For location requests, using the location button lets you give people an in-the-moment way to share their location; for guidance, see Using the Location Button.

Request permission at launch only when the data or resource is necessary for your app to function. People are less likely to be bothered by a launch-time request when it’s obvious why your app needs the information. If you want to perform app tracking as soon as people launch your app, you must display the system-provided alert before you collect any tracking data.

The system provides a standard alert that lets people view your request to access their private information or protected resources. You supply a description of why your app needs the items, and the system displays this description in the alert. People can also view your description — and update their choice — in Settings > Privacy.

Write copy that clearly describes how your app uses the data or resource you’re requesting. The standard alert displays your copy (called a purpose string or usage description string) after your app name and before the buttons people use to grant or deny their permission. Aim for a brief, complete sentence that’s straightforward, specific, and easy to understand. Use sentence case, avoid passive voice, and include a period at the end. For developer guidance, see Requesting Access to Protected Resources and App Tracking Transparency.

Example purpose string Notes
White check in a green circle to indicate a correct example. The app records during the night to detect snoring sounds. An active sentence that clearly describes how and why the app collects the data.
White X in a gray circle to indicate an incorrect example. Microphone access is needed for a better experience. A passive sentence that provides a vague, undefined justification.
White X in a gray circle to indicate an incorrect example. Turn on microphone access. An imperative sentence that doesn’t provide any justification.

Here are several examples of the standard system alert:

  • Screenshot of a permission alert for the Pal About app displaying a purpose string that reads ’Allow Pal About to access your location? Turning on location services allows us to show you when pals are nearby.’ Below the string is a small map image containing the Precise On notice and below the map are three buttons in a stack. From the top, the buttons are titled Allow Once, Allow While Using App, and Don’t Allow.

Using the Location Button

In iOS 15 and later, Core Location provides a button so people can grant your app temporary authorization to access their location at the moment a task needs it. Although a location button’s appearance can vary to match your app’s UI, it always communicates the action of location sharing in a way that’s instantly recognizable.

Image of a lozenge-shaped blue button that displays a white location indicator — that is, a narrow arrow head shape that points to the top right — followed by the text Current Location.

The location button grants your app temporary authorization to request the device location. If your app has no authorization status, tapping the location button has the same effect as when a person chooses Allow Once in the standard alert. If people previously chose While Using the App, tapping the location button doesn’t change your app’s status. For developer guidance, see LocationButton (SwiftUI) and CLLocationButton (Swift).

The first time people open your app and tap a location button, the system displays a standard alert. The alert helps people understand how using the button limits your app’s access to their location, and reminds them of the location indicator that appears when sharing starts.

Screenshot of the alert displayed by the location button that appears on top of a background image showing a partial map of the Western Hemisphere. The alert reads ’Park Finder can only access your location when you choose to share it. When you share your location with this app, a blue location indicator will appear in the status bar.’ Below this text the alert displays a small image of the map, zoomed in to show part of Cupertino. Below the map are two buttons; from the top the titles are OK and Not Now.

After people confirm their understanding of the button’s action, they simply tap the location button when they want to give your app one-time permission to access their location. Although each one-time authorization expires when people stop using your app, they don’t need to reconfirm their understanding of the button’s behavior.

Consider using the location button to give people a lightweight way to share their location for specific app features. For example, your app might help people attach their location to a message or post, find a store, or identify a building, plant, or animal they’ve encountered in their location. If you know that people often grant your app Allow Once permission, consider using the location button to help them benefit from sharing their location without having to interact with the alert.

Consider customizing the location button to harmonize with your UI. Specifically, you can:

  • Choose the system-provided title that works best with your feature, such as “Current Location” or “Share My Current Location”
  • Choose the filled or outlined location glyph
  • Select a background color and a color for the title and glyph
  • Adjust the button’s corner radius

To help people recognize and trust location buttons, other visual attributes aren’t customizable. The system also ensures a location button remains legible by warning you about problems like low-contrast color combinations or too much translucency. In addition to fixing such problems, you’re responsible for making sure the text fits in the button — for example, button text should fit without truncation at all accessibility text sizes and when translated into other languages.

IMPORTANTIf the system identifies consistent problems with your customized location button, it won’t give your app access to the device location when people tap it. Although such a button can perform other app-specific actions, people may lose trust in your app if your location button doesn’t work as they expect.

Using the Microphone in a ShazamKit App

ShazamKit enables audio recognition by matching an audio sample against the ShazamKit catalog or a custom audio catalog. In iOS 15 and later, apps can use ShazamKit to enable features like:

  • Enhancing app experiences with graphics that correspond with the genre of currently playing music
  • Making media content accessible to people with hearing disabilities by providing closed captions or sign language that syncs with the audio
  • Synchronizing in-app experiences with virtual content in contexts like online learning and retail

If you need the device microphone to get audio samples for your app to recognize, you must request access to it. As with all types of permission requests, it’s important to help people understand why you’re asking for access; for guidance, see Requesting Access Permission.

After you receive permission to access the microphone for features that have ShazamKit enabled, follow these guidelines.

Stop recording as soon as possible. When people allow your app to record audio for recognition, they don’t expect the microphone to stay on. To help preserve privacy, only record for as long as it takes to get the sample you need.

Let people opt in to storing your app’s recognized songs to their iCloud library. If your app can store recognized songs to iCloud, give people a way to first approve this action. Even though both the Music Recognition control and the Shazam app show your app as the source of the recognized song, people appreciate having control over which apps can store content in their library.

For developer guidance, see ShazamKit.

Displaying Custom Messaging Before the Alert

Ideally, people already know why you’re requesting their permission based on context, but if it’s essential to provide additional details, you can display a custom message before the alert appears.

Make it clear that opening the system alert is the only action people can take in your custom-messaging screen. People can interpret a pre-alert message as a delaying tactic, so it’s critical to let them quickly dismiss the message and view the system alert. If you display a custom screen that precedes a privacy-related permission request, it must offer only one action, which must display the system alert. Use a word like “Continue” to title the action; don’t use “Allow” or other terms that might make people think they’re granting their permission or performing other actions within your custom screen.

Screenshot of an app’s pre-alert screen that reads ’Allow tracking on the next screen for special offers and promotions just for you, advertisements that match your interests, an improved personalized experience over time. You can change this option later in the Settings app.’ Below the text is a button titled Continue.

White check in a green circle to indicate a correct example.

Screenshot of the Pal About app’s pre-alert screen that reads ’Turning on location services allows us to provide features like: Alerts when your pals are nearby, news of events happening near you, tagging and sharing your location.’ Below the text is a button titled Continue and below the button is the text ’You can change this later in the Settings app.

White check in a green circle to indicate a correct example.

Clarifying Tracking Requests

App tracking is a sensitive issue. In some cases, it might make sense to display custom messaging that clearly describes the benefits of tracking.

Never precede the system-provided alert with custom messaging that could confuse or mislead people. People sometimes tap quickly to dismiss alerts without reading them. A custom messaging screen that takes advantage of such behaviors to influence choices will lead to rejection by App Store Review.

There are several prohibited custom-messaging designs that will cause rejection. Some examples are offering incentives, displaying a screen that looks like a request, displaying an image of the alert, and annotating the screen behind the alert (shown below). For guidance, see App Store Review Guidelines: 5.1.1 (iv).

  • Screenshot of an app’s pre-tracking message that reads ’Allow tracking and get a $100 credit toward you next purchase.’ Below the text is an image of a dollar sign inside a circle. Below the image is a button titled Get $100 credit, followed on the line below by the word Cancel.

    White X in a gray circle to indicate an incorrect example.

    Don’t offer incentives for granting the request. You can’t offer people compensation for granting their permission, and you can’t withhold functionality or content or make your app unusable until people allow you to track them.

aso关键词技巧

首先,ASO本地化语言是说,在App Store的规则里,在中国覆盖关键词不但可以设置简体中文,还可以设置英语、日语、法语、德语等等一系列外国语言。每一种语言提供100个字符的空间。我们可以在外国语言版本中的字符空间覆盖简体中文关键词,以此提高关键词覆盖量。但是不是每一种语言版本的关键词都是有效的。

经过多年的实际操作经验来看,目前英文英语和英文澳大利亚是最有效果的。简体中文可以设置100个字符,英文(英语)版关键词可以设置100个字符,英文(澳大利亚)可以设置100个字符,加起来就有300个字符,关键词覆盖量直接翻了三倍。同样的,如果是做海外市场的小伙伴,除了当地语言版本外还可以多设置一版英语版的关键词。这就占了很多的优势。

在这里为做海外市场的小伙伴提供一份全球英语设置目录:

1、中国(应用商店):中文(简体)和英文(英国)英文(澳大利亚)
2、英文(英国)影响所有155个销售地区(除美国和加拿大)
3、美国(应用商店):英文(美国)和西班牙文(西班牙)
4、瑞士(应用商店):德文、法文、英文(英国)、意大利文(覆盖最多语言版本了)
通过本地化语言3个版本的关键词覆盖,再经过后台算法关联和联想,基本上关键词的覆盖量都能达到5000以上。可以想象一下,别人设置100个字符,你设置300个字符,覆盖量是别人的3倍。这就占据了很大的优势,建议有条件的就覆盖多语言版本的关键词。

今日起可提交申请:苹果App Store针对独立开发者和小企业的抽成费用降至15%

11月份的时候苹果宣布了一项App Store小企业项目,将降低对小企业的抽成费用。

苹果App Store的分成比例为30%,根据从2021年1月1日起启动的App Store小企业项目,针对年收入不足100万美元的小型企业和独立开发者,苹果将把App Store费用减免一半,从30%降低到15%。

从今天起,符合条件的开发者就可以注册了。

苹果目前已经开放了App Store小企业项目网站,符合条件的开发者应在太平洋时间2020年12月18日10:00之前提交申请,通过的开发者自2021年1月1日起可以享受15%的费用减免。

从App Store获得的年收入低于100万美元的开发者都可以申请,这适用于98%的开发者。新加入App Store的开发者也能够参与。

15%的费用适用于付费应用购买、应用内购买和订阅费用,100万美元的总额包括关联开发者账户,你和你的关联开发者账户必须在2020年内发生的12个财政月内获得的总收益(扣除苹果的佣金和某些税费及调整后的销售额)不超过100万美元,并且在本年度内的收益不超过100万美元。

在参与该活动期间,不允许应用转让,2020年12月31日之后发起的任何应用转让都会使开发者失去参与该计划的资格。