App Store Connect App Privacy Labels - A 90-Minute Data Inventory Pass for Unity and Godot iOS Builds (2026)

Why this matters now

App Store Connect treats App Privacy answers as part of your compliance surface, not a marketing sidebar. In 2026, teams that ship Unity or Godot games to iOS rarely write every analytics line by hand. You inherit behavior from the engine, plugins, ad mediation, crash reporters, authentication SDKs, and backend services. When your privacy nutrition labels under-describe collection, reviewers and players see a mismatch between the store story and runtime reality. When you over-describe out of fear, you shrink addressable audience and create internal arguments that slow submission.

This guide is a ninety-minute data inventory pass with one output: a single spreadsheet your producer can paste next to App Privacy in App Store Connect, aligned with what your shipping candidate binary can defend. It is not legal advice. It is an engineering and release-ops ritual that prevents “we will fix privacy later” from becoming your review-week bottleneck.

Pair this pass with our Google Play and App Store metadata policy checklist for Q2 2026 so listing copy, AI disclosure language, and privacy text stay one story. If you are also juggling Android the same month, cross-read Google Play pre-launch triage for Unity and Godot so Android stability work does not steal the owner of your data inventory thread.

Apple publishes official guidance on App Privacy details on Apple Developer (start from App Store Connect Help and linked privacy manifest documentation for third-party SDK expectations). Treat Apple’s docs as the authority when a teammate asks “does this SDK category still apply in 2026?” Your job in this pass is to map SDKs and endpoints to data types and uses with evidence, not vibes.

Who this is for and what you will ship in ninety minutes

Audience: Solo developers and small teams shipping Unity or Godot 4 to iPhone or iPad with at least one third-party SDK (ads, analytics, auth, social, crash, voice, anti-cheat).

Outcome: A data inventory table (SDK or subsystem, data category, purpose, linked to code or config path), a short risk note for your producer, and a list of App Privacy toggles you still need legal or DPO sign-off on.

Prerequisites: A release or release-candidate iOS build settings profile, not a prototype scene. Someone who can read Xcode build phases or your CI export logs at a basic level.

Time budget: Ninety minutes with two roles if possible. Owner A traces SDKs and native bridges. Owner B types the spreadsheet and captures screenshots of App Store Connect draft answers.

Beginner Quick Start - Vocabulary you should align on

App Privacy labels: The questionnaire in App Store Connect where you declare categories of data collection and linkage practices. Players see a summary derived from your answers.

Data linked to the user: Roughly, data that can be tied to an identity inside your app or across apps for that user, per Apple’s definitions at submission time. Your team should use Apple’s category text, not your internal analytics schema names, when arguing in the spreadsheet.

Tracking: Uses that match Apple’s App Tracking Transparency framing. If you show ads or share data with brokers for ad purposes, you need honest ATT posture in the product, not only a clean privacy label.

Privacy manifest and third-party SDKs: Many commercial SDKs ship privacy manifest fragments that declare declared data types. Your pass should reconcile manifests with actual runtime behavior when upgrades change defaults.

Unity as a collector: The engine and services you enable (analytics, ads, multiplayer) can collect device and usage signals even when your gameplay code is “simple.”

Godot on iOS: Exports wrap native code and plugins. GDExtension and iOS plugins can add collectors you did not list in GDScript.

Success check: The team agrees whether this build includes ads, crash reporting, and account login before you open App Store Connect.

What you are proving in plain language

You are proving three statements:

1. We listed every subsystem that can emit or read player-related data off device or into your backends.
2. We matched each subsystem to Apple’s data categories at the granularity App Privacy expects.
3. We flagged unknowns instead of silently answering “no collection” to feel safe.

Why App Privacy answers drift from shipping binaries

SDK upgrades without a privacy diff: A minor bump can enable a new analytics event class or change default ad mediation behavior. If your release notes only mention “bug fixes,” your App Privacy row can still be stale.

Conditional compilation you forgot about: A compile symbol that pulls in crash or performance reporting for release builds only means your editor smoke test is not a privacy test.

Shared service accounts across games: Backend endpoints that fingerprint installs for anti-fraud may not live in a branded SDK folder, but they still emit identifiers you must account for.

Third-party manifests versus your integration: Privacy manifest fragments describe what a vendor believes their library can collect. Your game may enable optional adapters or beta features that expand real collection beyond the default manifest story.

Handoffs between contractors: One team integrates social login; another ships live ops tools. Without a single inventory owner, App Store Connect becomes a patchwork of guesses.

This pass exists to collapse those failure modes into one reviewable artifact before submission week noise peaks.

Example rows (fictional game, realistic shape)

These rows are illustrative, not a template you can paste as legal truth. They show how engineers attach evidence to categories.

Your real table will be longer. The point is to tie each row to something a reviewer can trace.

The inventory table template (copy this header row)

| Subsystem | Example SDK or module | Data types (Apple categories) | Purpose (analytics, ads, app functionality, fraud, etc.) | Linked to user? (team draft) | Tracking? (team draft) | Evidence (file path, plist key, dashboard screenshot id) | Owner | Status |

Keep one row per SDK plus one row for your first-party backend if you operate matchmaking, cloud save, or accounts.

Unity teams - three timed blocks

Block 1 (0 to 25 minutes) - Freeze the candidate and list native bridges

1. Record Unity version, iOS target, IL2CPP versus Mono, and Xcode version used for archive.
2. Export a list of embedded frameworks and Swift Package dependencies from the generated Xcode project or your CI artifact manifest.
3. Paste CocoaPods or UPM iOS post-process plugins with version numbers.

Pro tip: If your ads and analytics packages differ between development and release, you are not allowed to answer App Privacy using the dev profile.

Block 2 (25 to 60 minutes) - Map SDKs to data types

For each SDK row:

1. Open the vendor’s iOS privacy or ATT documentation and copy their declared data types into your table.
2. Add your usage notes (for example, “rewarded ads only on settings screen”).
3. Mark unknown when docs conflict with your integration (for example, optional features you left enabled).

Cross-check Godot vs Unity mobile in 2026 if you are deciding how much mobile SDK surface your project should carry at all.

Xcode privacy signals: When your pipeline allows, run Apple’s privacy report flows on the archived app and paste export highlights into the evidence column. Treat the report as a hint list, not a substitute for vendor documentation, because your code path may disable modules the report still lists.

Embedded frameworks discipline: For each .framework bundle in the Xcode project, either map it to an existing spreadsheet row or create a new row marked investigate. Silent frameworks are how crash, anti-cheat, and attribution libraries hide until review questions arrive.

Block 3 (60 to 90 minutes) - Reconcile with App Store Connect draft

1. Open App Privacy in App Store Connect for the app record.
2. Walk each data type Apple lists and mark yes only when your spreadsheet supports it.
3. Capture screenshots of draft answers for the release packet.

If you are fighting install size pressure while adding SDKs, pair decisions with reduce install size before store review so privacy work does not silently expand binary weight.

Godot teams - three timed blocks (same rhythm)

Block 1 (0 to 25 minutes) - Template and export lock

1. Record Godot version and export template checksum.
2. List iOS plugins, GDExtension binaries, and one-off native modules.
3. Confirm whether you use GodotPayment, Game Center, or third-party social SDKs.

Block 2 (25 to 60 minutes) - Map collectors

Godot projects often under-count push notification tokens, cloud save, and multiplayer identifiers. Add explicit rows for each online service.

GDScript is not the whole story: If you ship a GDExtension or iOS plugin that wraps a commercial SDK, your inventory must include that native layer even when no GDScript file mentions “analytics.”

Export settings versus entitlement reality: Push, Game Center, and in-app purchase capabilities change which identifiers exist. Diff export_presets.cfg and the generated Xcode project when a teammate insists “we did not enable that.”

Block 3 (60 to 90 minutes) - App Store Connect draft parity

Same as Unity Block 3. The questionnaire does not care which engine you used.

The ninety-minute agenda (calendar-ready)

Minutes 0 to 10 - Confirm ads, login, analytics on or off for this candidate.
Minutes 10 to 35 - Build the SDK list with versions.
Minutes 35 to 70 - Fill data types and purposes from vendor docs plus first-party notes.
Minutes 70 to 85 - Mirror into App Store Connect draft answers.
Minutes 85 to 90 - Email producer three sentences: what we collect, what we are unsure about, what needs legal.

Common mistakes that waste review weeks

Answering “no data collected” because gameplay is offline
Plugins may still phone home for licensing, crash, or ads.

Letting marketing write App Privacy alone
Marketing needs the spreadsheet, not the other way around.

Ignoring “optional” SDK features left on by default
Defaults count as shipped behavior until you prove they are compiled out.

Treating ATT as only an iOS dialog
ATT posture and privacy labels must tell a coherent story.

Skipping push notification and Game Center rows
Identifiers and account linkage still matter for App Privacy.

When to pull legal or a DPO into the loop

Pull legal when you have children’s audiences, health-adjacent data, precise location, contact info, or financial data. This pass should highlight those rows early with evidence links, not reinterpret regulations for them.

How this pass pairs with Android work

You will reuse much of the spreadsheet for Google Play declarations, but category wording differs. Maintain one master inventory and two store-specific views so you do not fork truth during a dual-store week.

When Android is in the same milestone, schedule Google Play pre-launch triage on a different calendar block so stability meetings do not swallow privacy meetings.

Producer one-pager (paste under your inventory link)

Game:
Build id or TestFlight version:
Ads: on / off (evidence link)
Accounts: on / off (evidence link)
Analytics + crash: on / off (evidence link)
Push: on / off (evidence link)
Kids audience: yes / no / unknown
Open legal tickets: none / list

Plain-language summary (three sentences max):

This block keeps leadership alignment boring, which is how you avoid last-minute rewrite App Privacy panic.

Key takeaways

• App Privacy is an engineering artifact, not a solo marketing form, for Unity and Godot iOS games with real SDK depth.
• Freeze the release candidate before you answer data questions, or your labels describe the wrong binary.
• One spreadsheet row per SDK plus first-party backend rows prevents silent under-counting.
• Vendor privacy docs are the first evidence layer, but you must reconcile optional features and version drift.
• Unknown is a valid interim status that beats false negatives in the questionnaire.
• ATT, ads, and analytics deserve explicit rows even when gameplay is “simple.”
• Screenshots of draft App Privacy answers belong in your release evidence packet.
• Dual-store teams should keep one inventory with two store-facing views.
• Pair with metadata and listing policy checks so store copy and privacy text match.
• Escalate child, health, location, contact, and financial data to legal early with evidence links.
• Xcode privacy reports are hints that still require vendor doc reconciliation and framework mapping.
• Producer one-pagers prevent leadership from treating App Privacy as a last-hour checkbox.

FAQ

Does this replace a privacy policy?

No. Your privacy policy URL still must describe practices in human language. This pass feeds accuracy for App Store Connect.

We only use Unity Analytics. Do we still run the full pass?

Run a shortened pass that still lists every enabled service, including crash and performance tools.

What if two SDKs both collect device IDs?

List both rows and explain why in the evidence column. Reviewers care about honesty and linkage, not minimal row counts.

Our game has no ads today. Can we skip ad SDK rows?

Skip only if ads code is not in the shipping binary. Verify with a symbol or dependency scan, not memory.

How often should we rerun this pass?

At minimum before each submission that changes SDK versions, authentication, or online features.

We only ship on TestFlight to friends. Can we defer App Privacy?

No for the public TestFlight track you intend to widen. Treat every widening step as a chance for label drift if SDKs move.

What if two owners disagree on “linked to user”?

Keep both interpretations in the notes column, mark the row legal review, and do not force App Store Connect to pretend certainty.

Do server-side-only logs count?

If your app sends the data off-device, you usually still declare the types that leave the phone. Server retention is a policy topic your privacy policy must cover.

Should we document ATT prompt timing in this pass?

Yes. Capture when the prompt appears relative to first value from ad or attribution SDKs, and store the screenshot id in your evidence packet.

What about Apple’s Required Reason APIs?

When Apple flags APIs that need approved reasons, your inventory should reference the same build where you generated privacy reports, not an older archive.

Conclusion

App Store Connect App Privacy rewards boring honesty. The ninety-minute inventory pass turns SDK sprawl into a review-ready table, lowers the odds of a label-versus-binary mismatch, and gives your producer something concrete to stand behind during submission week. Keep Apple’s App Store Connect reference open, keep your metadata policy checklist aligned with copy, and treat unknown rows as tickets, not shame.

Related reading on GamineAI

• Google Play and App Store metadata policy changes Q2 2026
• Godot vs Unity mobile in 2026
• Reduce install size before store review
• Google Play pre-launch report triage

External references

• Apple Developer: App Store Connect Help
• Apple Developer: User privacy and data use