App Privacy Details: What to Declare

Ridge Notes is a hiking app. It draws a trail on a map, saves that trail on the phone, and can copy it to the user’s iCloud if they turn that on. There is no ad network and no data broker. The App Privacy details you file for that app should describe those facts. They should not describe a generic “mobile app collects analytics,” and they should not mark tracking because a crash reporter exists. Tracking is a defined term. Analytics is a purpose. They are not the same switch.

Apple’s app privacy details page is what you are filling in. The product page then shows some of the data types you may collect, and whether that data is linked to the person or used to track them. You need this to submit a new app or an update. Account Holder, Admin, and App Manager can edit the answers, and you can change them later without shipping a new binary. The privacy policy URL on the product page is required. The label and that policy have to tell the same story. Age range is a different form. It is covered in Apple’s declared age range, and this post will not re-explain that API.

The three buckets on the product page

Shoppers see three groups. Data used to track you meets Apple’s tracking definition. Data linked to you is tied to an account, a device, or other details. Data not linked to you was de-identified before collection, with no attempt to re-identify it. Personal information, as privacy laws define it, counts as linked. Anonymizing later does not move a type into the not-linked bucket.

Declare every type you or a partner collects, unless it meets all of Apple’s optional-disclosure tests: not tracking, not an ad or other listed purpose, infrequent, not the app’s main job, and clearly submitted by the user each time. A trail recorded on every hike fails that test. Ongoing collection after one permission still has to be disclosed.

What tracking means, and what it does not

Tracking means linking data from your app about a user or device, such as a user ID or device ID, with third-party data for targeted ads or ad measurement, or sharing that data with a broker. Third-party data comes from apps, sites, or offline properties you do not own. An SDK that combines your users with other developers’ users to target ads counts, even if you did not mean to turn that on.

Data that stays on the device, and is not sent off in a way that identifies the user, is not tracking. A broker used only for fraud prevention or security is not tracking. Crash logs are an analytics purpose unless they are linked with third-party data for ads or handed to a broker. Do not tick tracking because an SDK’s marketing says analytics.

Ridge Notes, bucket by bucket

Ridge Notes declares location as linked data used for the map, declares optional iCloud trails as linked user content, may declare de-identified crash logs as not linked, and does not declare tracking.

Location, trails, and iCloud

Precise Location is the hiker’s coordinates. Ridge Notes needs it for the map, so declare it as linked, purpose app functionality. Do not mark it shared with a third party you do not have. If you only keep a region, declare Coarse Location instead. Do not declare both just in case.

Trails that never leave the phone are not a server collection. Optional iCloud is different: Apple says data you collect through CloudKit has to be declared. When sync is on, the trail is linked to that iCloud account as user content for app functionality. Mention the practice on the label because the app can collect it. The privacy policy should say the same thing: on the phone by default, iCloud only if they opt in, not used for ads.

Crash logs and the not-linked test

Diagnostics on Apple’s list includes Crash Data and Performance Data. A crash log is worth declaring if a vendor receives it. It belongs in Data Not Linked to You only when you meet Apple’s test: direct identifiers such as user ID or name are stripped before collection, you do not try to link the log back, and you do not join it to a dataset that would. If the crash SDK sends a device identifier you can match to a support email, the log is linked. Say so. Calling it “anonymous analytics” does not move the bucket.

If a first-party analytics endpoint receives screen events, declare that usage data, pick analytics or app functionality, and then apply the linked versus not-linked test. Analytics as a purpose is allowed. It is not, by itself, tracking.

The policy, the page, and Play

The privacy policy URL is required on the product page. Privacy Choices is optional. Write the policy so it names location for the map, on-device trails, optional iCloud, and crash logs if you have them. If the label says you do not track, the policy cannot describe an ad partner. A mismatch is how you get a metadata fight, which is guideline 2.3 territory and the subject of the metadata rejection guide. The privacy policy guide is where the URL itself gets written. This post is only the nutrition label.

Google Play asks a different form, with collected versus shared and a security section. Do not paste these three Apple buckets into Play Console. Use the Data safety guide for the Android build of the same hike. Screenshots of the map should show the trail, not a badge that says “zero data” if the label lists location. AppGrowthKit can frame that map. It cannot file the form. Guideline 4.3, if you were hoping a privacy tweak would save a clone, is a product problem and a separate article.