A privacy manifest and a permission-purpose string are different declarations. Derive them from actual behavior and dependencies rather than filling fields with generic text.

Inventory data use → Inspect SDK behavior → Declare reasons → Review release archive
  1. 1Inventory data use
  2. 2Inspect SDK behavior
  3. 3Declare reasons
  4. 4Review release archive

Work through the example

Trace one permission to the feature that asks for it and the user-visible explanation. Recheck dependencies when they change.

Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.

Implementation reference

The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.

Privacy

  • [ ] Privacy policy URL provided (required for all apps)
  • [ ] Privacy policy is accessible and clearly written
  • [ ] App Privacy labels configured in App Store Connect (Data Types questionnaire)
  • [ ] Each data type categorized correctly (collected vs. tracked vs. linked)
  • [ ] App Tracking Transparency (ATT) prompt implemented if tracking users across apps
  • [ ] ATT prompt shown before any tracking begins
  • [ ] NSUserTrackingUsageDescription added to Info.plist if using ATT
  • [ ] Purpose strings (usage descriptions) provided for all permission requests:
  • [ ] NSCameraUsageDescription
  • [ ] NSPhotoLibraryUsageDescription
  • [ ] NSLocationWhenInUseUsageDescription
  • [ ] NSLocationAlwaysAndWhenInUseUsageDescription (if applicable)
  • [ ] NSMicrophoneUsageDescription
  • [ ] NSContactsUsageDescription
  • [ ] NSCalendarsUsageDescription
  • [ ] NSBluetoothAlwaysUsageDescription
  • [ ] NSFaceIDUsageDescription
  • [ ] NSHealthShareUsageDescription / NSHealthUpdateUsageDescription
  • [ ] Each purpose string clearly explains why the permission is needed (in user-friendly language)

Acceptance and failure review

Checkpoint What to inspect If it does not match
Inventory data use Confirm the input and environment Preserve the failure and return to this step
Inspect SDK behavior Inspect the intermediate artifact Preserve the failure and return to this step
Declare reasons Run the focused check Preserve the failure and return to this step
Review release archive Record the observed result Preserve the failure and return to this step

Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.

Evidence and limits

Current Apple requirements must be checked for the actual release; this is not legal advice or submission approval.

This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.

Inspect the source used in this lesson.

What to do next

Next: Preparing for TestFlight: signing, builds and account boundaries