You built your app and you are ready to submit. Then Apple or Google rejects it because your privacy policy is missing, incomplete, or does not match what your app actually does. This is a frequent mistake for solo founders who treat the privacy policy as an afterthought.
To pass review and reduce later risk, your privacy policy has to match your app behavior, store disclosures, and SDK activity. You need a policy that matches reality across both app stores, the privacy laws that may apply now, and the practical constraints of launching without hiring a lawyer.
Apple privacy requirements have multiple layers
Before you submit, your policy URL and App Store Connect declarations must line up with any required privacy manifest files. A policy can exist and still fail review if any of these layers are out of sync.
Privacy policy URL in two locations
Apple documentation requires a publicly accessible privacy policy URL in two separate places: the App Store Connect metadata field and inside the app itself, typically on a Settings screen. The App Review Guidelines require the privacy policy URL to be available both in the app and in App Store Connect.
Privacy nutrition labels
Before submitting any app or update, you must complete a privacy label in App Store Connect. For each data type your app collects, you declare whether data is linked to user identity, whether it is used for cross-app tracking, and the purpose of collection. You must also declare data collected by third-party SDKs in your build.
Privacy manifest file
Apps that use required reason APIs or include SDKs that use those APIs must include a privacy manifest file (PrivacyInfo.xcprivacy) in their build. This file declares the required reason API usage codes for your app and the reasons your app uses each API category. Completing your App Store Connect declarations does not satisfy this requirement. Apple checks these items separately.
AI data disclosure
Apple added a rule under Guideline 5.1.2(i) in its guidelines update. If your app sends user data to OpenAI, Anthropic, Google Gemini, or another external AI API, disclose what data is sent and identify the recipient in your privacy policy. Apple review also expects accurate privacy disclosures and user permission before sharing personal data with third parties where applicable.
Google Play has its own mandatory requirements
If you ship on both platforms, run a separate check for Play Console requirements. The structure is simpler than Apple's, but incorrect fields can still block publishing.
Data Safety section and privacy policy
Google Developer Program Policy requires a privacy policy for apps that collect or process user data, and many apps need one to publish on Google Play. The policy must be hosted at a publicly accessible working URL without access restrictions. It must accurately describe the user data the app collects and how the app uses or shares it.
You must also complete a Data Safety form in Play Console. This form covers data types collected by your app and bundled SDKs, along with the purpose of each collection. You must declare whether data is shared with third parties and whether collection is optional or required.
Account deletion requirement
If your app lets users create accounts, Google requires account deletion as a readily discoverable option from within the app. You also need an external deletion URL entered in a designated Play Console field. You must delete data associated with the account upon deletion request, unless you have a valid reason to retain certain data.
Key differences from Apple
Google Play has no equivalent to the Apple App Tracking Transparency prompt. Google does not require a privacy manifest file. Google does explicitly mandate account deletion with a Play Console URL field, which Apple does not require in the same way.
Privacy laws may apply regardless of company size
Store approval does not remove legal exposure. Several laws can still apply to small teams with a small user base.
FTC Act (Section 5)
The FTC mobile app guidance states it directly: "Laws that apply to established businesses apply to you, too, and violations can be costly." If your privacy policy says you protect user data, you must actually do it. If a bundled SDK violates your privacy promises, that is still your responsibility.
GDPR
If your app processes personal data in connection with offering goods or services to people in the EU, or monitoring their behavior there, GDPR can apply. There is no revenue or size threshold for core obligations. Organizations with fewer than 250 employees may be exempt from formal Records of Processing Activities. That exemption only applies if processing is occasional, low-risk, and excludes special data categories. Other GDPR obligations still apply, including lawful basis, privacy notices, data subject rights, and breach notification.
COPPA
COPPA applies if your app is directed to children under 13 or if you gain actual knowledge that children are using it. The first COPPA enforcement targeting a mobile app involved a single developer who paid $50,000 for collecting childrens email addresses without parental consent.
The sensitive data trap in state laws
Many state privacy laws use consumer-count thresholds that small founders may fall below, but those thresholds are only part of the analysis. A 2025 policy analysis found that Connecticut's amended CTDPA treats sensitive data processing as a standalone coverage trigger, which means a business may fall under the law based on the type of data it processes. Sensitive data includes precise geolocation, health information, biometrics, and financial account information.
Your SDKs shape what you must disclose
Founders often document their own features correctly, then miss the data collection that starts when an SDK is added. Your SDK inventory needs the same review as your own features.
Apple documentation requires developers to disclose data collection and privacy practices related to third-party code and SDKs integrated into their app. Google Play takes the same position in its data disclosure rules.
Here is what common SDKs collect:
- Firebase Analytics: Starts collecting data automatically when added. Collected data includes device model, OS, carrier, WiFi/LTE info, country based on IP, app version, and Firebase Installation ID. You are the data controller; Google is the processor.
- Firebase Crashlytics: Collects crash stack traces, device info, and Installation UUID by default. Retained for 90 days. Your privacy policy should disclose that crash-related information collected through Crashlytics may be shared with Google.
- Google AdMob: Collects IP address, user interactions, diagnostic info, and advertising identifiers. Requires ATT on iOS. If you use mediation partners, each must be added to AdMob privacy and messaging settings.
- RevenueCat: Collects purchase transaction data, app user IDs, locale, and currency. Does not collect payment card details.
- OpenAI API: Sends whatever user content you include in prompts. Does not train on customer data by default. If you send personal data, your policy should describe that sharing accurately.
Use this list as a starting point, then verify every SDK in your own build before you update the policy and store disclosures.
A recent FTC post about third-party SDK compliance reinforced the same point. Developers remain responsible for third parties collecting data on their behalf.
How to create a compliant policy without spending thousands
Once you know what your app and SDKs collect, the next job is turning that inventory into a document you can keep current. For a first launch, you need a policy that matches reality more than a custom legal project.
For most indie founders at the validation stage, a purpose-built generator can produce a functional policy. That approach may be enough for an initial launch if you review every clause against your actual stack.
You should get legal review if your app is directed at children. The same applies when raising investment or negotiating Data Processing Agreements for B2B clients.
Real rejections and enforcement cases to learn from
Mismatches between disclosures and actual data handling can block submission or create legal risk later. Use the cases below as a final check before you ship.
ITMS-91061 (iOS)
Apps that include a privacy-impacting SDK without a PrivacyInfo.xcprivacy file may be rejected by App Review. Developers raised privacy-manifest-related questions about the Zoom SDK on the Zoom forum. If the SDK vendor has not updated its package, your options may be limited.
Missing AI consent (iOS)
As of the guidelines update, Apple requires apps to obtain user permission before sharing personal data with third parties and to provide information about how and where that data will be used. Apps that skip this step risk rejection.
FTC enforcement against Match Group
The FTC took action against OkCupid for sharing user data with an unauthorized third party in direct violation of its stated privacy policy. A policy that promises limited sharing while data goes beyond those boundaries can create FTC Act risk when actual practices do not match the representation.
AI chatbot category
The FTC launched a formal inquiry into AI companion chatbots, focusing on data handling and impacts on children. If you are building in this category, expect closer scrutiny.
Keep your policy in sync with the app
Keeping your policy aligned with SDK behavior and store declarations lowers submission risk and legal risk. Update the policy when you add an SDK or integrate an AI API. Do the same for any change that expands into a new data category. If you use Anything as your AI app builder, review what your stack collects before every submission and keep the disclosures current. Then use the mobile publishing docs as your next step before you submit your app to the App Store.
