App Store Guideline 5.1.1: Data Collection and Storage

The guideline text#

Quoted verbatim from Apple's App Review Guidelines, which the page states were last updated June 8, 2026. We checked the text on October 3, 2026. Apple revises the guidelines and sometimes renumbers sub-items, so compare this against the live page before you cite it in a reply to App Review.

Guideline 5.1.1 has ten sub-items. The ones a health or fitness app most often runs into are quoted below. The others cover password discovery, SafariViewController, compiling personal information from other sources and optional contact information.

5.1.1 Data Collection and Storage

(i) Privacy Policies: All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner. The privacy policy must clearly and explicitly:

• Identify what data, if any, the app/service collects, how it collects that data, and all uses of that data.

• Confirm that any third party with whom an app shares user data (in compliance with these Guidelines)—such as analytics tools, advertising networks and third-party SDKs, as well as any parent, subsidiary or other related entities that will have access to user data—will provide the same or equal protection of user data as stated in the app’s privacy policy and required by these Guidelines.

• Explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user’s data.

(ii) Permission: Apps that collect user or usage data must secure user consent for the collection, even if such data is considered to be anonymous at the time of or immediately following collection. Paid functionality must not be dependent on or require a user to grant access to this data. Apps must also provide the customer with an easily accessible and understandable way to withdraw consent. Ensure your purpose strings clearly and completely describe your use of the data. Apps that collect data for a legitimate interest without consent by relying on the terms of the European Union’s General Data Protection Regulation (“GDPR”) or similar statute must comply with all terms of that law. Learn more about Requesting Permission.

(iii) Data Minimization: Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task. Where possible, use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.

(iv) Access: Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, provide alternative solutions for users who don’t grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.

(v) Account Sign-In: If your app doesn’t include significant account-based features, let people use it without a login. If your app supports account creation, you must also offer account deletion within the app. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law. If your core app functionality is not related to a specific social network (e.g. Facebook, WeChat, Weibo, X, etc.), you must provide access without a login or via another mechanism. Pulling basic profile information, sharing to the social network, or inviting friends to use the app are not considered core app functionality. The app must also include a mechanism to revoke social network credentials and disable data access between the app and social network from within the app. An app may not store credentials or tokens to social networks off of the device and may only use such credentials or tokens to directly connect to the social network from the app itself while the app is in use.

(ix) Apps that provide services in highly regulated fields (such as banking and financial services, healthcare, gambling, legal cannabis use, air travel and crypto exchanges) or that require sensitive user information should be submitted by a legal entity that provides the services, and not by an individual developer. Apps that facilitate the legal sale of cannabis must be geo-restricted to the corresponding legal jurisdiction.

What it means for a fitness or health app#

• 5.1.1(i): every app needs a privacy policy linked in two places, in App Store Connect and inside the app. The policy has to cover three points: what you collect, how and for which uses; equal protection from any third party you share with, which Apple says includes analytics tools, ad networks and third-party SDKs; and retention, deletion and how users revoke consent. Our health app privacy policy page covers the content in more detail.
• 5.1.1(ii): consent and purpose strings. Collecting user or usage data needs consent, even when you consider the data anonymous. Users need an easy way to withdraw consent. Paid features can't depend on granting data access. Purpose strings must "clearly and completely describe your use of the data".
• 5.1.1(iii) and (iv): ask for less, and don't push. Request only data relevant to the app's core function. Respect the user's permission settings and don't "manipulate, trick, or force" consent. Where possible, offer an alternative for users who decline.
• 5.1.1(v): logins and account deletion. Let people use the app without a login unless it has significant account-based features. If users can create an account, they must also be able to delete it from inside the app.
• 5.1.1(ix): healthcare is a "highly regulated field". Apps providing services in healthcare should be submitted by the legal entity that provides the services. The guideline doesn't say where a fitness app ends and a healthcare service begins, so if your app is close to that line, decide which side it is on before you submit.

What typically triggers it in a HealthKit app#

These come from the guideline text and Apple's own developer documentation, not from a log of rejections.

• Missing or vague purpose strings. Apple's HealthKit documentation is blunt about the first failure: "Apps must include usage descriptions, or it will crash when you request authorization to access HealthKit data." It names the keys too: "Include the NSHealthShareUsageDescription key to read, and NSHealthUpdateUsageDescription key to write data to Healthkit." A string that is present but generic ("This app uses Health data") has a harder time meeting the "clearly and completely" bar in 5.1.1(ii). If authorization fails or reads come back empty, see HealthKit authorization denied.
• Asking for every type at first launch. Apple's HealthKit documentation says: "you don’t need to request permission for all data types at once. Instead, it might make more sense to wait until you need to access the data before asking for permission." Requesting types no feature uses conflicts with 5.1.1(iii).
• A paywall that needs Health access. A subscription feature that won't run until the user grants HealthKit access conflicts with 5.1.1(ii).
• Deactivation instead of deletion. Apple's account-deletion guidance says: "Offer to delete the entire account record, along with associated personal data. You may include additional options, but only offering to temporarily deactivate or disable an account is insufficient." It also says apps outside highly regulated industries "should not require people to make a phone call, send an email, or go through other support flows". Apple adds that apps using Sign in with Apple "should use the Sign in with Apple REST API to revoke user tokens".
• Guest accounts with no delete option. The same guidance says users should be able to delete automatically created "guest" accounts and their data.

Checklist before you resubmit#

1. Link the privacy policy in both places. Add the privacy policy URL to the App Store Connect metadata field and put an easily found link inside the app, for example in settings. Guideline 5.1.1(i) requires both.
2. Make the policy cover the three required points. Check that the policy states what data you collect, how and for what uses; that third parties you share with give the same or equal protection; and what your retention and deletion policy is, including how a user revokes consent or requests deletion.
3. Rewrite the HealthKit purpose strings. Make the read and write usage descriptions (NSHealthShareUsageDescription and NSHealthUpdateUsageDescription) say plainly what you read or write and why. Guideline 5.1.1(ii) asks that purpose strings clearly and completely describe your use of the data.
4. Request only the types a feature uses, when it needs them. Remove HealthKit types no shipped feature reads or writes, and consider asking at the moment a feature needs the data. Apple's HealthKit documentation says you don't need to request all types at once.
5. Unlock paid features without requiring data access. Make sure no purchased or subscribed feature refuses to work until the user grants Health or other data access. Guideline 5.1.1(ii) says paid functionality must not depend on it. Where you can, offer a fallback such as manual entry, as 5.1.1(iv) suggests.
6. Ship in-app account deletion if users can create accounts. Put deletion where users can find it, usually in account settings. It should delete the account record along with the associated personal data, not just deactivate it. If a website finishes the process, link straight to that page. If deletion takes time, say how long and confirm when it is done.
7. Check whether your app needs a login at all. If the app has no significant account-based features, let people use it without signing in, as 5.1.1(v) requires.
8. Submit as the legal entity if you provide healthcare services. If your app provides services in healthcare, guideline 5.1.1(ix) says it should be submitted by the legal entity providing them, not by an individual developer account.

Related#

• For what Apple says you may do with the data after collecting it, see guideline 5.1.2: Data Use and Sharing. For the extra health-specific rules, see guideline 5.1.3: Health and Health Research.
• For deletion on the data side, see health data retention and deletion. For all of Apple's health-data rules in one place, see the App Store health data rules overview.

A note on limits#

Apple's account-deletion guidance describes deletion as removing the account "along with any data associated with the account that the developer isn’t legally required to maintain", and tells you to follow applicable legal requirements for retention. Data you are legally required to keep is not part of what Apple asks you to delete. App Store rules are contractual, not law, and meeting them doesn't settle your obligations under GDPR or state consumer-health laws. This page is general guidance, not legal advice.