User data in an app: what to ask for and what not to

An app should ask only for the data it needs to do the job it promises, at the moment it needs it, and say why. That's what the GDPR requires, what Apple and Google require before they publish your app, and it's also what keeps people from uninstalling after the first screen.

The basic rule: only what the feature needs

The GDPR says personal data must be adequate, relevant and limited to what's necessary for the purposes it's processed for, collected for specified purposes and kept no longer than needed. Article 25 goes further: by default, only the data needed for each specific purpose gets processed.

Apple says almost the same thing: an app should only ask for data tied to its core function.

Here's a simple exercise for a salon booking app:

Every extra row is data you have to protect, declare and delete on request.

Permissions: ask when the user taps the feature

Location, camera, microphone and photos are requested through a system dialog. The classic mistake is to ask for all of them on first launch, before the user even knows what the app does.

Google's Android guidance boils down to a few principles:

• ask for a permission in context, when the user starts using the feature that needs it;
• explain why beforehand, because the system dialog says what you want but not why;
• if the user says no, the app keeps working with that feature turned off, with no screens that block them.

There's a practical reason too: on Android, if the user taps "Deny" twice for the same permission, the system stops showing the dialog. Ask too early and you've lost it.

Apple asks for the same: apps must not trick or force people into granting access to data they don't need and, where possible, should offer an alternative. Their example: if someone won't share their location, let them type an address instead.

Accounts: don't make them mandatory without a reason

Apple's guidelines are direct: if your app doesn't have significant account-based features, people should be able to use it without logging in. A restaurant menu doesn't need an account; an app with order history does.

And if an app lets people create an account, it has to let them delete it from within the app. Apple requires this, and Google Play requires an in-app path to delete the account and its associated data, plus a web link where people can request deletion without reinstalling the app. Google's deadline for completing the form was December 7, 2023, with a possible extension to May 31, 2024; after that, apps that don't comply can be removed from the store.

What you declare in the stores

Before publishing, you fill out two forms:

• App Store, "App Privacy": what data the app collects, including through code from partners you integrate (analytics, ads, payments), whether it's linked to the user and whether it's used for tracking. The information appears on the app's App Store page and is required for new apps and updates.
• Google Play, "Data safety": what data you collect and why, what you share, whether it's encrypted in transit and whether users can request deletion. Even apps that collect nothing have to fill out the form, and a privacy policy is required.

This is where surprises tend to show up: an analytics or ad library added "for later" collects data you have to declare. That's why we put together the data list alongside the feature list, not at the end.

Checklist

1. For every form field: which feature uses it?
2. Every permission: is it requested when the user taps the feature, with an explanation first?
3. Does the app still work, at least partly, if the user says no?
4. Can it be used without an account, if it doesn't need one?
5. Can the account be deleted in the app and on the web?
6. Do the App Privacy and Data safety forms say exactly what the app does, including third-party libraries?
7. Do you know how long you keep each piece of data and when you delete it?

We plan data and permissions together with the screens; see how we work on our App Dev services page.