Handling App Store Privacy Nutrition Labels

Key facts, with sources

• App store search drives 65% of app discovery on iOS and 58% on Google Play, making it the single largest acquisition channel ahead of browse, referrals, and ads. (Business of Apps)
• In 2025 the average US conversion rate was 8.56% on the App Store and 16.15% on Google Play, with category extremes ranging from about 5% for trivia games to over 50% for food and drink apps. (AppTweak)
• A one-star rating increase can lift conversion 10 to 15%, and moving from three to four stars can boost conversions by up to 89%. (AppFollow)
• Apple Ads placements at the top of App Store search results deliver an average conversion rate above 60% across available countries, measured November 2024 to October 2025. (Digital Applied (ASO statistics compilation))
• Apps compete against roughly 1.96 million titles on the Apple App Store and over 1.5 million on Google Play, with tens of thousands of new apps published every month. (BuildFire)

Your labels cover the whole binary, not your code

The mental model that gets teams in trouble is answering the questionnaire for the code they wrote. Apple's rules are explicit: the label must cover data collected by the app as shipped, including every third-party SDK compiled into it. A typical React Native app links in analytics, crash reporting, push, auth, and sometimes attribution SDKs via npm packages — each with native code that can collect device identifiers, usage data, and diagnostics whether or not you ever read that data yourself.

So the honest starting point is an inventory. If your label says 'Data Not Collected' while your binary embeds a crash reporter and an analytics SDK, it is simply wrong, and it is wrong in a way that Apple, researchers, and increasingly enterprise customers can detect by watching network traffic.

Auditing a React Native dependency tree

JavaScript-only packages cannot collect anything on their own; the native modules are what matter. I start from the iOS Podfile.lock rather than package.json, because it lists the actual native pods compiled into the binary, including transitive ones pulled in by other SDKs. For each vendor SDK, pull the vendor's published privacy disclosure — most major SDK vendors now document exactly which label categories their defaults trigger and which depend on your configuration.

Configuration matters as much as presence. An analytics SDK with identifier collection disabled declares differently than the same SDK with defaults. Record each decision in a simple table — SDK, data types, linked-to-identity or not, tracking or not, source of the claim — and keep it in the repo. That table is what turns the next label update from archaeology into a diff.

Categories, 'linked to you', and the tracking trap

Apple's questionnaire has three dimensions that teams conflate: what data types are collected, whether they are linked to the user's identity, and whether they are used for tracking. Linkage means the data is tied to an account or identifiable device profile — most authenticated apps collect at least identifiers and usage data linked to identity. Tracking has a narrower, specific meaning: joining app data with other companies' data for advertising or ad measurement, or sharing it with data brokers.

The trap is inconsistency. If your label declares data 'Used to Track You', reviewers and users expect an App Tracking Transparency prompt in the app; conversely, embedding an attribution SDK while declaring no tracking is a red flag. In privacy-sensitive B2B markets, my default advice is to configure SDKs so that tracking is genuinely off, and let the label reflect that truthfully.

Privacy manifests: the enforcement mechanism

Labels used to be pure self-declaration; privacy manifests added teeth. Apps and many third-party SDKs now ship a PrivacyInfo.xcprivacy file declaring collected data types and the 'required reason' APIs they touch — things like UserDefaults and file timestamps — with approved reason codes. Xcode aggregates these into a report you can compare against your label, and missing or inconsistent manifest entries can generate warnings or rejections at submission.

In Expo projects the app-level manifest is configurable from app.json, which keeps it in code review alongside the dependency changes that necessitate it.

{
  "expo": {
    "ios": {
      "privacyManifests": {
        "NSPrivacyAccessedAPITypes": [
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
            "NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
          }
        ]
      }
    }
  }
}

Keeping labels honest — and conversion-friendly — over time

Labels drift. A growth experiment adds an attribution SDK, a support feature adds a chat widget, and six months later the label describes an app that no longer exists. The fix is procedural: label review is a line item in my release checklist, triggered specifically by any dependency change that touches native code. Google Play's Data safety form is a separate declaration with its own taxonomy, so the same audit feeds two artifacts — answer them from one source of truth or they will contradict each other.

There is also a conversion angle worth taking seriously. A long 'Data Used to Track You' section is visible on your listing and reads as hostile, particularly to enterprise buyers whose security teams screenshot it. Often the cheapest label improvement is not wording — it is actually turning off collection you never use, then declaring the smaller truth.

When to hire senior help

Bring in ASO help once the product has retention worth scaling and organic installs have plateaued, since optimization multiplies traffic you already earn rather than creating demand. Specialists matter most in competitive categories, where keyword targeting and conversion testing against entrenched incumbents is a data discipline generalist marketers rarely run well. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — App Store Optimization projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Stuffing keywords into the app title despite Apple's 30-character limit and policy, while leaving the separate iOS keyword field empty or full of duplicates
• ✕Never running screenshot or icon experiments with Google Play store listing experiments or Apple Product Page Optimization, even though the first screenshot dominates conversion
• ✕Ignoring ratings mechanics: no in-app review prompt at moments of user success and no replies to negative reviews, letting the average drift below the critical 4.0 threshold
• ✕Treating ASO as a one-time launch checklist instead of iterating on keyword rankings and conversion data, and skipping listing localization for non-English markets

Frequently asked questions

Sources

• Business of Apps
• AppTweak
• AppFollow
• Digital Applied (ASO statistics compilation)
• BuildFire