There is no official Apple tool that auto-generates your iOS Privacy Nutrition Label from your app, so the honest answer to the search for a generator is that you complete the App Privacy questionnaire yourself in App Store Connect, and it is required before you can submit. You declare every data type your app collects, whether it is linked to the user's identity, and whether it is used to track them, and you must include data collected by third-party SDKs, not just your own code. The closest thing to a generator is the privacy manifest workflow: your app and its SDKs ship privacy manifest files that Xcode aggregates into a privacy report, which, together with each SDK vendor's published disclosures, tells you what to declare.
Short answer
Apple does not provide a one-click generator that reads your binary and fills the label; the label is a self-declared questionnaire. Per Apple's App Privacy details guidance, you must provide information about your app's privacy practices, including those of third-party partners whose code you integrate, and this is required to submit apps and updates. You complete it in App Store Connect, declaring data types, whether each is linked to the user, and whether it is used for tracking. The supported way to do this accurately, per Apple's manage app privacy help, is to use the privacy manifests your app and its SDKs provide, which produce a privacy report to inform your answers.
Is there a Privacy Nutrition Label generator?
Not an official one that fills the label for you. Apple's Privacy Nutrition Label is built from answers you give in the App Privacy section of App Store Connect, so it is a self-declaration rather than something derived automatically from your code. Every app must complete it, because Apple requires the App Privacy information before you can submit a new app or an update, so it is not optional and not skippable.
Third-party tools that market themselves as label generators can help you organize your answers, but they cannot know what your specific app and its SDKs collect, so they are aids to filling the questionnaire, not a substitute for knowing your own data practices. The reliable inputs are what your code does and what your SDKs disclose, which the privacy manifest workflow below surfaces. So treat the label as something you produce from accurate knowledge of your app, not something a generator produces for you.
What the label requires
The label requires you to declare, for every kind of data your app collects, what it is, why you collect it, whether it is tied to the user, and whether it is used to track them. Apple organizes this into categories on the product page: data used to track you, data linked to you, and data not linked to you, and within those you select from defined data types such as contact info, identifiers, location, health, financial info, usage data, and diagnostics, along with the purposes for each.
So completing it is a matter of going data type by data type and answering honestly. For each type you collect, you indicate whether it is linked to the user's identity and whether it is used for tracking, which is what determines the category it falls under. There are narrow cases where data does not have to be disclosed, for example certain data that is not used for tracking, is not linked with third-party data for advertising, and is not shared with a data broker, but the safe default is to account for everything your app collects and let the criteria narrow it down.
Third-party SDK data
You are responsible for declaring not only what your own code collects but also what third-party code in your app collects, which is where many labels go wrong. Apple states that if you use third-party code such as advertising or analytics SDKs, you must describe what data that code collects, how it may be used, and whether it is used to track users, and that your responses must cover the practices of third-party partners whose code you integrate. So an analytics or ad SDK collecting identifiers is your app collecting them, for label purposes.
This mirrors Google Play, where third-party SDK data must be declared too, and it is the most common reason a label is inaccurate. To get it right, list every third-party SDK in your app and consult each vendor's published privacy disclosures, since SDK providers document what their SDK collects specifically to help you fill the label. Then fold that into your declaration so the label reflects the whole app, not just your code.
The privacy manifest is the closest thing to a generator
If you want the label to be as automatic as it can be, the privacy manifest system is the mechanism to use. Your app and, increasingly, the third-party SDKs it includes ship a privacy manifest file that declares the data types they collect and the reasons for certain sensitive API uses, and Xcode aggregates these into a privacy report. That report gives you a consolidated view of what your app and its SDKs collect, which is exactly the input you need to answer the App Privacy questionnaire accurately.
So while there is no button that submits the label for you, the privacy manifest workflow is the supported path to producing an accurate one, and Apple introduced it, along with signatures for third-party SDKs, specifically to make Privacy Nutrition Labels more accurate and the supply chain more trustworthy. Use the privacy report as your source of truth for what is collected and transfer that into the App Privacy answers, which is far more reliable than a generic generator.
How to complete it, step by step
Completing the label happens in App Store Connect, informed by the privacy report and SDK disclosures. Open your app, go to the App Privacy section under the app's information, and start the questionnaire. For each data type your app or its SDKs collect, add it, then specify the purposes, whether it is linked to the user, and whether it is used for tracking, working from your privacy report so nothing is missed.
Once you have entered every data type across your own code and third-party SDKs, save and publish the App Privacy information, and it appears as the Privacy Nutrition Label on your product page. Because it is required to submit, finishing it accurately is part of getting through submission, and because you can edit it, you update it whenever your data practices change. So the procedure is short, but its accuracy depends entirely on having identified everything your app collects first.
Categories at a glance
The label sorts your declared data into three categories based on your answers. The table below summarizes them.
| Category | What it means | Determined by |
|---|---|---|
| Data Used to Track You | Data linked to third-party data for ads, or shared with a broker | You mark the data as used for tracking |
| Data Linked to You | Data tied to the user's identity, not for tracking | You mark it as linked but not tracking |
| Data Not Linked to You | Collected but not tied to the user's identity | You mark it as not linked |
Read the categories as outputs of your answers: how you classify each data type on linkage and tracking is what places it, so the classification decisions are the real work.
Keep it accurate and up to date
The label is not a one-time task, because you are responsible for keeping your responses accurate and current as your app changes. If you add an SDK, a feature that collects new data, or change how existing data is used, you update the App Privacy answers to match, since the label on the product page must continue to reflect what the app actually does. An out-of-date label is an inaccurate label.
This matters beyond tidiness, because an inaccurate Privacy Nutrition Label can lead to problems at review and undermines the trust the label is meant to provide. The point for completing the label is simply that accuracy is ongoing: fill it from a true picture of your data collection, and revisit it whenever that picture changes, particularly when you add or update third-party SDKs.
Completion checklist
Working through these steps produces an accurate label. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| List your data | Identify what your own code collects | [ ] |
| List SDK data | Check each third-party SDK's disclosures | [ ] |
| Use the privacy report | Aggregate app and SDK privacy manifests | [ ] |
| Classify each type | Set linked and tracking for every data type | [ ] |
| Complete App Privacy | Enter it all in App Store Connect | [ ] |
| Update on change | Revisit when practices or SDKs change | [ ] |
The step teams skip most is listing SDK data, since forgetting what a third-party analytics or ad SDK collects is the most common cause of an incomplete or inaccurate label.
Where a scan fits
An accurate label depends on knowing exactly what your app and its SDKs collect, which is easier to confirm when you can inventory the third-party code and data behavior in your build.
A scanner like PTKD.com analyzes your app build and reports the third-party SDKs it contains and the data-related behavior in it, such as identifiers and network endpoints, alongside security issues, by severity and mapped to OWASP MASVS. To be clear about the boundary: PTKD does not fill in your App Privacy questionnaire or generate the label, which is yours to declare in App Store Connect. It helps you see what SDKs and data collection are actually in your app, so the label you produce reflects reality rather than guesswork.
What to take away
- There is no official Apple generator that auto-fills the Privacy Nutrition Label; you self-declare it in the App Privacy section of App Store Connect, and it is required to submit.
- You declare every data type your app collects, whether it is linked to the user, and whether it is used for tracking, across three categories.
- You must include data collected by third-party SDKs, not just your own code, which is the most common thing developers forget.
- The closest thing to a generator is the privacy manifest workflow, where app and SDK manifests aggregate into a privacy report you use to answer accurately.
- Keep the label updated as your app and SDKs change, and use a tool like PTKD.com to see what data and SDKs are actually in your build.
