How to Fix App Store Guideline 1.3 Kids Category SDK Rejection
Audit analytics, crash-reporting, subscription, advertising, and other third-party SDK data flows after an Apple Kids Category rejection.
Direct answer
Do not decide from the SDK name alone. Start with the exact archived build Apple reviewed and determine what every embedded SDK can collect or transmit in the release configuration. Kids Category apps generally should not include third-party analytics or advertising, and Apple allows third-party analytics only in limited cases where the service does not collect or transmit IDFA or identifiable information about children, their location, or their devices. If an SDK sends a device identifier, account identifier, usage event, diagnostic payload, or another value that can identify a user or device, remove or reconfigure that data flow, rebuild, and resubmit. Clarify or appeal only when the reviewed binary already meets the rule and you can prove the SDK inventory, configuration, and observed network behavior for that exact build.
Match the wording in your rejection
“Includes third-party analytics”
Inventory every library that reports usage, performance, attribution, experiments, or diagnostics. Apple describes third-party analytics as an exception for Kids Category apps, not a default allowance, and the limited case excludes identifiable child, location, and device information.
“Collects, transmits, or has the capability to share personal or device information”
Inspect the shipped configuration and runtime behavior, not only your intent. Device IDs, account IDs, IP-derived data, persistent installation identifiers, user attributes, and payload metadata can be relevant even when the SDK is used for crash reporting or purchases rather than advertising.
App Review names an SDK you believe is not used for analytics
Do not argue from the product category of the vendor. Show what modules are embedded, which features are enabled, what fields leave the device, the recipient and purpose, and why none of the transmitted fields can identify a child or device under the Kids Category rule.
The app was rejected again after analytics was disabled
Confirm that the old framework, transitive dependency, initialization code, remote configuration, cached identifier, and release-only endpoint are absent from a newly archived build. A dashboard toggle alone may not change the submitted binary or all runtime traffic.
What this rejection usually means
A Guideline 1.3 SDK rejection is a release-artifact and data-flow problem. Apple makes the developer responsible for third-party code, while privacy manifests and App Privacy answers describe practices rather than proving that a Kids Category build is allowed to perform them. Review can flag analytics, advertising, crash reporting, purchase infrastructure, attribution, remote configuration, support tools, or a transitive dependency when the shipped code can send personal or device information to another company. The useful question is therefore not whether an SDK is popular or whether you personally use its analytics dashboard. The question is what the exact release binary contains, initializes, and transmits in every child-accessible state.
Likely rejection signals
- The archive embeds an analytics, advertising, attribution, crash-reporting, performance, subscription, support, experimentation, or remote-configuration SDK
- An SDK receives IDFA, IDFV, a vendor installation ID, account ID, user attributes, IP-derived information, location, usage events, diagnostics, or custom payload fields
- A dependency remains in the signed archive after its feature was disabled in source code or a vendor dashboard
- Development and release configurations initialize different modules, endpoints, consent defaults, or remote flags
- The privacy manifest, Xcode privacy report, vendor documentation, observed traffic, and App Privacy answers do not describe the same data flow
- Reviewer instructions explain the app but do not identify the third-party SDKs, their purposes, or the child-safe release configuration
- The team assumes crash or purchase data is automatically exempt because it is not used for advertising
Recovery plan
- Preserve the full rejection, reviewer attachment, app version, build number, device and OS. Export or retain the exact archive Apple reviewed before changing dependencies so every claim remains tied to the reviewed artifact.
- Generate a complete SDK inventory from the archive and dependency lockfiles. Include direct and transitive frameworks, extensions, dynamic libraries, build plugins, and code injected only in the Release configuration. Record the installed version and module for each dependency.
- Build a data-flow table for every third party: initialization point, data fields, source, recipient, purpose, retention or linkage where known, and child-accessible states. Treat device and installation identifiers, account identifiers, network information, diagnostics, custom metadata, and purchase history as fields to investigate rather than assuming they are harmless.
- Use privacy manifests and Xcode's combined privacy report as inputs, then verify them against current vendor documentation and the configured release. Apple says the developer remains responsible for all third-party SDK code; a manifest or signature is not an approval certificate for Guideline 1.3.
- Observe the clean-install release behavior. Test first launch, guest and signed-in states, parental area, purchase and restore flows, crashes, offline recovery, foreground and background transitions, and remote-config variants. Capture the destination host and transmitted field names while avoiding real child data in the test evidence.
- Choose the safest compliant implementation. Remove advertising and nonessential analytics from the Kids build. For crash, performance, subscription, or other essential services, disable unnecessary modules and identifiers, strip custom user data, avoid attaching child or device attributes, and replace the service with first-party, on-device, or Apple-provided functionality when the remaining third-party behavior cannot be shown to meet Guideline 1.3.
- Archive a new release and repeat the inventory. Confirm that removed frameworks and transitive packages are absent, stale initialization code cannot run, remote configuration cannot re-enable the behavior, and observed traffic matches the intended minimum data flow.
- Reconcile App Privacy answers and the public privacy policy with the corrected release, including the practices of third-party partners. Accurate disclosure is required, but disclosure does not make a data flow permissible for the Kids Category.
- Write Review Notes for the new build. Name the removed or reconfigured SDK modules, state which third parties remain and why, summarize the tested data fields, and attach a short SDK/data-flow matrix plus clean-install evidence. Give App Review the exact parental-gate path for purchases or links when relevant.
- Resubmit when the binary, SDK configuration, or data flow changed. If the exact rejected build was already compliant, reply in the existing App Review thread with build-specific evidence and request clarification or a retest before considering an App Review Board appeal.
Evidence to prepare
- Complete rejection message, reviewer attachment, review device and OS, app version, build number, and exact archived release
- Direct and transitive SDK inventory with versions, modules, lockfiles, frameworks, extensions, and Release-only dependencies
- Per-SDK data-flow matrix listing fields, identifiers, recipients, purposes, initialization states, and configuration
- Privacy manifests and Xcode privacy report reconciled with current vendor documentation and actual release behavior
- Clean-install network or SDK diagnostic evidence covering guest, account, parental, purchase, restore, crash, and remote-config paths
- Before-and-after archive comparison proving removed modules, identifiers, initialization code, and endpoints are absent or minimized
- Published App Privacy answers and privacy policy that match the corrected release and all third-party partners
- Concise Review Notes with the exact build, completed changes, retained services, parental-gate path, and attachments
Appeal or fix first?
Clarify first when the exact reviewed archive already fits Apple's limited case and your evidence shows that no third party collects or transmits IDFA or identifiable information about children, their location, or their devices. Ask App Review to identify the SDK, field, or runtime path still at issue. Appeal only if the same factual finding remains after a documented retest and the appeal can point to evidence from the exact reviewed build.
Fix and resubmit when any third party receives personal or device information outside the narrow rule, the data flow is uncertain, a disabled SDK remains embedded or initializes, Release behavior differs from your test configuration, or App Privacy and the privacy policy do not match the binary. When you cannot verify a vendor's behavior, removal or a first-party alternative is stronger than an unsupported assurance.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the exact app version and build and quote the specific Guideline 1.3 concern you addressed.
- List the SDK modules removed or retained and describe only completed release changes.
- State the verified fields each remaining third party receives and why the flow meets the cited rule; avoid claiming that an entire vendor is universally Kids Category compliant.
- Attach the archive inventory, configuration summary, observed release evidence, and updated privacy disclosures.
- Request review of the corrected build, or ask for the specific SDK, field, or path if Apple believes a documented compliant build still violates the rule.
Frequently asked questions
Are all third-party SDKs forbidden in a Kids Category app?
Apple's rule specifically says Kids Category apps should not include third-party analytics or advertising and permits limited cases under stated conditions. Other SDKs still need a release-specific audit because Kids Category apps may not send personally identifiable or device information to third parties, and the developer is responsible for embedded code.
Can a Kids app keep a crash-reporting SDK?
Do not assume yes or no from the label alone. Verify what the exact release transmits, including device or installation identifiers, diagnostics, custom metadata, account data, and network information. Keep it only when you can show the configured data flow complies; otherwise remove it or use a first-party or on-device alternative.
Does a privacy manifest prove that an SDK complies with Guideline 1.3?
No. Apple says privacy manifests summarize privacy practices and help produce accurate disclosures. You remain responsible for the SDK's code and actual data collection, and a disclosed data flow can still be incompatible with the Kids Category rule.
Is IDFV safe because it is not IDFA?
Guideline 1.3's limited analytics language excludes not only IDFA but also information that can identify children or their devices, directly or in combination. Treat IDFV and other persistent device or installation identifiers as fields requiring a specific compliance justification, not an automatic exemption.
Should I appeal after removing the SDK?
Usually submit the corrected build because the binary changed. Appeal is better reserved for a factual dispute about an unchanged reviewed build that you can support with archive, configuration, and runtime evidence.
Can I leave the Kids Category to avoid the rejection?
Apple says an app must continue to meet Kids Category requirements after customers expect it to do so, even if the category is later deselected. Do not reposition the app as a shortcut; request case-specific guidance if the original category selection was genuinely mistaken.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Apple App Review Guidelines — 1.3 Kids Category. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.