Your app's privacy label was right the day you wrote it

The label ages faster than the app

When your app launched, someone sat down with App Store Connect and answered Apple's privacy questions. Maybe they did the same for Google Play's Data safety form. They knew the app well, and the answers were right.

That was a while ago. Since then, marketing asked for an attribution tool. Support added a chat widget. Engineering swapped crash reporters and updated a dozen SDKs. An embedded web view now loads the loyalty page, with its own tracking. None of that went back to the person who filled in the label.

The label describes the app you shipped, not the one you're running now. On your store page, customers see whatever was true at launch.

What the stores actually ask

Both stores put this on you, and both include other people's code.

Apple says you need to identify all the data that you or your third-party partners collect, and it defines third-party partners as analytics tools, ad networks, third-party SDKs and other vendors whose code you've added. It says you're responsible for keeping your answers accurate and up to date, and that if your practices change, you should update them. You can do that in App Store Connect at any time without submitting a new build. Apple's SDK guidance adds that when you use a third-party SDK, you're responsible for all the code it includes.

Google is just as direct. It says you alone are responsible for complete and accurate declarations in your Data safety section. That includes data handled by third-party libraries and SDKs, and by web views your app controls. When Google becomes aware of a discrepancy between what your app does and what you declared, it says it may take enforcement action.

The definitions catch people out

Part of the drift is that the questions are narrower than they look, so a label can be wrong even when everyone meant well.

Apple's definition of "collect" is about data leaving the device. It means sending data off the phone in a way that lets you or a partner keep it for longer than it takes to handle the request in real time. A crash reporter that uploads logs with a user ID counts. So does a chat widget that stores conversations on the vendor's servers.

Purpose doesn't get you out of it either. Apple says that even if you collect data only to make the app work, not for analytics or advertising, you still declare it and mark it as used for app functionality.

There is an optional-disclosure route, but Apple says a data type has to meet every one of its criteria to qualify, including not being used for tracking or advertising and being collected only in infrequent, optional cases. Meeting some of them isn't enough. When in doubt, declare it and describe the use honestly.

Where the drift comes from

These are illustrative, but they're the usual sources:

• A new analytics or attribution SDK that collects device identifiers or links activity across apps.
• A support chat widget that collects names, emails and message contents.
• An SDK update that quietly added a feature, such as location or contacts access, the old version didn't have.
• A web view inside the app loading a page with its own pixels.
• A removed tool whose data types are still declared. Over-declaring isn't a security risk, but it makes your app look worse than it is next to competitors.

Apple gives you a useful tool here. When you build for distribution, Xcode combines the privacy manifests from the third-party SDKs in your app into a single report. Apple also lists commonly used SDKs that must include a privacy manifest when you add them. The report won't fill in your label for you, but it tells you what the code says it collects, and that's where the conversation should start.

Make it part of release, not launch

The fix is ownership, not heroics.

Name an owner. One person, usually a product owner or tech lead, owns the label on both stores. They don't have to know every SDK. They have to be asked.

Trigger the review on change. Any pull request that adds, removes or upgrades an SDK, or adds a web view, gets a line in its description: does this change what we collect? If yes, the owner updates the label before release.

Compare against the build. For each release, glance at Xcode's privacy report and your Android dependency list against what you declared. Note the date you checked.

Keep the vendor's own disclosure. Many SDK providers publish their own privacy or Data safety guidance. Google points to its SDK Index for this. Save a link next to each SDK in your records, so the next person doesn't have to hunt.

Remember the testing tracks. Google says the Data safety form applies to apps on closed, open and production tracks, with internal testing as the exception.

If you're thinking about other places where the shipped app and your records disagree, our notes on old app versions still running and what strangers can read in your app binary are related.

This week

Open your App Store listing and your Google Play listing on a phone and read the privacy sections as a customer would. Then list every SDK and web view in the current build and match them to what's declared. Fix the gaps in App Store Connect and Play Console, write down who owns it from now on, and add the one-line question to your pull request template. It takes an afternoon the first time and a few minutes per release after that, which is a good trade for a page every customer can read before they install.

If you'd like a team to keep your app, its SDKs and its store disclosures in step release after release, that's the mobile application development work we do. Talk to us.

Related work: PatientIQ.