Can we just declare the maximum and stay safe?

Over-declaring costs you clarity with users and can raise questions in review about data the app does not use. It also hides the SDK that really does collect something, which is the one you needed to see. We declare what the inventory shows, and we remove what serves no purpose so the declaration gets shorter.

Do we need App Tracking Transparency if we only use analytics?

It depends on what the analytics SDK touches. If it reads the advertising identifier or follows the user across other companies' apps and sites, the prompt applies, and so do the tracking questions in the App Privacy details. Aggregate product analytics that never touch that identifier usually sits outside it. We check the SDK documentation and the traffic rather than assuming either way.

Our current Data safety form is already wrong. What happens now?

We correct it at the next submission. Google expects the form to be accurate at the time of the release rather than perfect forever, so the practical step is to fix it before the next update goes out. Where the mismatch is material, we tell you what exposure it created and whether anything needs to be disclosed to users.

How do you handle a deletion request when the data sits in a third-party SDK?

Data held inside an ad network or analytics vendor is reached through that vendor's deletion API or dashboard, which is why the inventory lists the vendors and their data types first. We map each stored field to the system that owns it, then build the deletion path across all of them, including the copies in backups and logs.

Our app is used by teenagers in some markets. Does anything change?

Yes, and the trigger is age rather than market. Apple's Kids Category, Google's Families policy, COPPA, and the age of consent under GDPR Article 8 each set rules on collection, parental consent, and behavioural advertising for younger users. One underage audience segment pulls the stricter requirements into the product, so we configure the age gate and the ad settings accordingly.

Mobile App Privacy Compliance

App Privacy labels and Google Play data safety forms that match the code, plus SDK inventory, consent, and GDPR or CCPA request handling.

See our work:

Voice VPN - Fast VPN. Vasilkoff Ltd in-house project→Walking Cure→COINAGE WALLET→

Two reviewers ask the same question about your app, and both expect the answer to match what the code does. Apple's App Privacy details, Google's Data safety form, and your privacy notice get read by people who then use the product and compare. A declaration that understates collection is the mismatch a store reviewer can find, and the first thing a regulator reaches for later.

Teams fill those forms from memory, or from a dependency list someone opened once during development. Nothing keeps them true after an SDK version bump or a mediation adapter arriving as a transitive dependency. We reconcile the declarations with the build artifacts and the app's traffic, then leave you a process for the next release.

What this covers

Apple's App Privacy details describe, for each data type, whether you collect it, whether it is linked to the user, whether it is used for tracking, and for which purposes. Google's Data safety form asks similar questions and adds encryption in transit, a deletion request path, and third-party sharing. Both stores require an in-app way to delete an account.

App Tracking Transparency applies when the app touches the advertising identifier or follows a user across other companies' apps and sites, and a refusal has to change what the app does. Consent covers where permission is captured, how it is withdrawn, and what loads after a refusal, including the signals your ad and analytics partners expect.

Regulatory requests cover access, deletion, export, and correction under GDPR and its UK equivalent, plus the CCPA and CPRA rights. Retention sets how long each field lives. Children's data brings age gates, Kids Category rules, the Families policy, COPPA, and the GDPR Article 8 age of consent.

Building an SDK inventory you can defend

The inventory gets assembled from the build itself, using four cross-checked sources.

Start with the resolved dependency graphs. On iOS that means Podfile.lock and Package.resolved; on Android the full transitive tree from gradlew app:dependencies, since mediation adapters and analytics wrappers arrive that way without anyone adding them deliberately.

Then read the shipped artifact: unpack the IPA or the AAB and list the frameworks, native libraries, and SDK class names inside. Modern iOS SDKs ship a privacy manifest, PrivacyInfo.xcprivacy, declaring the data each library collects, so the archive carries vendor-written statements. The Android merged manifest shows permissions such as com.google.android.gms.permission.AD_ID, plus the receivers and services each library registers.

Then watch the app run. Behind a proxy on a clean device we record which domains are contacted at first launch, during signup, on a screen showing an ad, and during a forced crash. Traffic catches what static reading misses: a library that talks before the user has chosen anything, and one pulled in without being declared.

Finally we map each package to the vendor's published data collection documentation and the store's own SDK guidance, then write one row per SDK: name, version, vendor, data types, purpose, whether the data is linked to the user, whether it supports tracking across other apps and sites, and which form field it feeds.

The result is a table you can check line by line, rerun before each submission, since a minor version bump can add a data type nobody announced.

Who this is for

Apps carrying ad, attribution, or analytics SDKs, where several companies receive user data your team never wrote. Fintech, wallet, VPN, and health products, where collection questions arrive with a regulatory deadline attached. Products with users in the EU, the UK, or California, and apps whose audience includes children or teenagers.

What we deliver

The reconciled text for both store forms, built from the inventory. Privacy policy sections that match the forms and the app's behaviour. The App Tracking Transparency implementation, with the purpose string, prompt timing, and what happens after a refusal. A consent flow wired to the partners' consent signals. Request handling for access, export, and deletion, with verification so one user cannot delete another user's data. A retention schedule for each stored field. Age gate and Families configuration where it applies. A submission checklist naming which SDK collects what and why.

Where the project starts

Three starting points change the emphasis.

A plain idea with nothing built yet is the cheapest version of this work. The SDK list becomes a decision made on purpose, retention periods get chosen with the database schema, and the consent screen is designed with the tracking it controls.

An existing conventional codebase usually has labels and a policy that were accurate when written. We diff them against the current dependency graph, list the mismatches, and correct whichever side is wrong.

An AI or vibe-coded prototype tends to arrive with analytics or ad libraries added while features were still being tested, and a policy generated from a template describing a different product. We rebuild the inventory from the artifact, remove what serves no purpose, and declare what remains, which protects the idea and the early users.

How the engagement runs

We start with the build, the store listings, the current policy, and the analytics dashboards. The first phase is the inventory plus a gap list: every place where the declaration, the policy, and the observed behaviour disagree.

The second phase is decisions. Some SDKs can be removed, some initialised only after consent, and some declared as they are, with the choice and the reason recorded.

Implementation follows: consent flow, tracking prompt, request endpoints, retention jobs, policy text, and the store forms filled from the inventory table. A deletion screen that only clears the app is worse than no screen, so the request path lives in your API.

Verification runs on a clean install with a proxy attached, confirming that nothing requiring consent fires early, that a refusal suppresses the SDK it covers, and that deletion removes the record and its copies. Then we support the submission.

What it costs

Privacy work runs at our flat rate of $39 per hour, and once the inventory exists we can usually quote the rest as a fixed scope, because the inventory is what removes the guesswork. A single-platform app with a short SDK list takes days. An ad-supported app on both platforms, with analytics and attribution partners, EU and UK users, and server-side deletion and export, takes several weeks, because each partner has its own documentation.

Where the privacy setup is part of a new build, the published mobile MVP typical order on our pricing page is $4,800 to $8,500 across four to six weeks, which is the stage where the inventory and consent design are cheapest to add. Teams shipping every few weeks use the monthly capacity plan from $2,699, so declarations get checked with each submission.

Proof

Voice VPN is our own Flutter VPN for restricted networks, with no accounts, no traffic logs, and monetisation built on ads, credits, and referral rewards. It shows what privacy-first architecture looks like when the requirement comes first, and why the inventory still matters: an ad-supported product declares the advertising data its partners collect.

Coinage Wallet is an exchange platform we built and customised on the Peatio foundation, with security-focused work around balances and transactions for a client-facing launch. It shows we work inside accounts and money flows where privacy and security are reviewed together.

Walking Cure was a clinic website for a California practice explaining a walking-based health method, with treatment content, a blog, and a contact form. It shows how we treat an enquiry form on a health topic: the fields, the purpose, and the retention of what arrives are part of the design.

Related services

Mobile app development for the builds this work runs against, native or Flutter
Mobile app security audit and hardening for the technical side of protecting the same data: storage, tokens, keys, and API access
App Store and Google Play publishing when the submission, the listing, and any rejection need handling
App analytics and crash reporting setup for instrumenting a product so collection stays inside what you declare
API development and integration for the server endpoints behind deletion, export, and retention

Next step

Send us the app build, the store listings, and your current privacy policy. We will tell you where the declarations and the code disagree.