Apple's privacy manifests, Google Play's Data safety form, the EU's Digital Services Act and India's DPDP Act all changed what a store submission has to get right, in a fairly short window. Many of the rejections and review delays teams now run into are policy issues rather than technical ones, and most are preventable with a checklist run before you press submit.
Apple's privacy manifest, in plain English
Apps and third-party SDKs declare, in a privacy manifest, the data they collect and why they use certain "required reason" APIs (file timestamps, system boot time, disk space, user defaults and a few others). Xcode aggregates these into a privacy report for your app. Since May 2024 Apple has required these declarations for uploads to App Store Connect, and SDKs on Apple's list of commonly used third-party SDKs must ship their own manifest and signature.
The fix is usually to update SDKs to versions that include manifests — most major ones (Firebase, Sentry, Branch, OneSignal) did so during 2024 — and then declare your own code's required-reason API usage. Generate the privacy report before every release and actually read it. It is also the quickest way to spot an SDK collecting more than you expected, and your App Store privacy label should match it.
Google Play Data safety: the form that bites
Google's Data safety section requires you to declare every type of data your app collects or shares, why, whether it is encrypted in transit, and whether users can request deletion. It covers data collected by SDKs inside your app, which is where most mismatches come from. A declaration that does not match what the app actually does is a common trigger for rejections and policy notices.
Account deletion is the other frequent catch. If users can create an account in your app, both stores require a way to delete it: Apple expects it inside the app, and Google expects an in-app path plus a web link declared in Play Console.
India DPDP Act: build for it now
India's Digital Personal Data Protection Act, 2023 is being phased in. The DPDP Rules were notified in November 2025, and most obligations on businesses — notice, consent, security safeguards, breach reporting and user rights — take effect 18 months later, around May 2027. Apps serving Indian users are better off building for them now than retrofitting later. In practice that means:
- A clear, standalone notice and consent flow for personal data, not buried in T&Cs, available in English or any language listed in the Eighth Schedule of the Constitution.
- Withdrawing consent made as easy as giving it, plus a way to request correction and erasure.
- Published contact details for someone who can answer data-protection questions. A Data Protection Officer based in India is mandatory only for entities the government notifies as Significant Data Fiduciaries.
- A process to report personal data breaches to the Data Protection Board and affected users within the timelines the Rules set.
- Extra care with children's data: verifiable parental consent is required for users under 18.
EU Digital Services Act
The DSA has applied to all online intermediaries since February 2024. If you distribute in the EU and your app has user-generated content or recommender systems, it brings notice-and-action for illegal content, statements of reasons when you remove content, and transparency about how recommendations work; micro and small enterprises are exempt from some of the platform duties. Separately, both Apple and Google ask developers distributing in the EU to declare whether they are a "trader" under the DSA, and traders have their contact details shown on the store listing.
United States: state privacy laws and children
There is no single federal privacy law for apps, but state laws such as California's CCPA, as amended by the CPRA, require notice at collection, a way to opt out of the sale or sharing of personal information, and honouring deletion requests. If your audience includes children under 13, COPPA applies, and both stores add their own rules for apps in kids' categories.
The submission checklist we run
- Privacy manifest generated and validated, Xcode privacy report reviewed (Apple).
- App Store privacy label matched to the manifest and to actual app behaviour (Apple).
- Data safety form completed and matched against actual app behaviour, including every SDK (Google).
- Privacy policy and T&Cs reviewed for each target market and linked both from the listing and inside the app.
- Consent flows tested with reviewer-style adversarial paths: deny everything, then try to use the app.
- Account-deletion flow shipped and easy to find, with the web deletion link for Google Play.
- DSA trader status declared for EU distribution.
- Reviewer notes and a working demo account supplied for anything behind a login.
- Region-specific store listing and screenshots reviewed.
If a submission has been rejected
- Read the exact guideline or policy cited and reply with specifics, not a generic apology.
- Fix the root cause across the whole app, not only the flow the reviewer tested.
- Update your declarations (manifest, privacy label, Data safety form) so the metadata matches the new build.
- If you believe the reviewer is mistaken, use the store's appeal route and include a short screen recording.
How we ship this at Velura Labs
Every Mobile App Development engagement includes a store-submission compliance pass: privacy manifests, the Data safety form and regional consent flows. Read our Flutter vs React Native guide for the stack-side considerations. Talk to us if a recent submission was rejected and you need a clean resubmission.
Velura Labs delivers this for teams across the United States — Seattle (Washington), San Francisco and Los Angeles (California), Austin and Dallas (Texas), and New York — as well as Europe (Paris, Milan, Rome and the wider EU), the Middle East (Dubai, Abu Dhabi and Riyadh) and India. Talk to us wherever you operate.