On this page 8 sections
The two documents everything here comes back to are Apple’s App Review Guidelines and the App Review page. Both change; read them again before each major release.
The four layers of privacy on iOS
Privacy requirements come in layers, and it helps to keep them apart:
- Permission prompts. The system asks the user before your app can use the camera, location, contacts, photos and so on, using a purpose string you write.
- App Tracking Transparency. A separate prompt, required before tracking people across other companies’ apps and websites.
- Privacy manifests. A file in your app (and in each SDK) declaring what data is collected, whether it’s used for tracking, and why certain sensitive APIs are used.
- App Privacy details on the App Store, often called privacy nutrition labels: what you tell people on your product page in App Store Connect.
These must agree with each other and with what the app really does. Inconsistency between them is a common reason for rejection.
Permission prompts and purpose strings
Every protected resource needs a usage description key in Info.plist, such as NSCameraUsageDescription or NSLocationWhenInUseUsageDescription. Apple’s App Review page says that the purpose string should clearly and completely describe how your app will use the data, and that an example helps.
Compare:
- Weak: “This app needs access to your camera.”
- Clear: “Your camera is used to scan the barcode on a parcel so you don’t have to type the tracking number.”
Ask at the moment the feature is used, not at launch. Someone who has just tapped “Scan barcode” understands why the camera is needed; someone who has just opened the app for the first time doesn’t, and is likely to say no. If they refuse, the feature should explain what’s missing and offer a way to continue, such as typing the number instead, with a link to Settings for people who change their mind:
import AVFoundation
import SwiftUI
struct ScanButton: View {
@State private var cameraDenied = false
@Environment(\.openURL) private var openURL
let onAuthorised: () -> Void
var body: some View {
Button("Scan barcode", systemImage: "barcode.viewfinder") {
Task {
switch AVCaptureDevice.authorizationStatus(for: .video) {
case .authorized:
onAuthorised()
case .notDetermined:
if await AVCaptureDevice.requestAccess(for: .video) { onAuthorised() } else { cameraDenied = true }
default:
cameraDenied = true
}
}
}
.alert("Camera access is off", isPresented: $cameraDenied) {
Button("Open Settings") { openURL(URL(string: UIApplication.openSettingsURLString)!) }
Button("Type it instead", role: .cancel) { }
} message: {
Text("You can still enter the tracking number by hand.")
}
}
}App Tracking Transparency
If your app tracks users, meaning it links data collected in your app with data from other companies’ apps or websites for advertising or measurement, or shares it with data brokers, you must ask permission through the App Tracking Transparency framework first, and include NSUserTrackingUsageDescription. Apple’s definitions and examples are on the User Privacy and Data Use page.
Many apps don’t need to track at all. First-party analytics that stay with you, crash reports and fraud prevention aren’t tracking in Apple’s definition, although they still need to appear in your privacy details. Not tracking is simpler for review, for your privacy policy and for your users’ trust.
Privacy manifests
A privacy manifest is a property list named PrivacyInfo.xcprivacy that you add to your app target in Xcode (File › New › File, then App Privacy). It has four top-level keys, all documented under Privacy manifest files:
NSPrivacyTracking: whether the app or SDK uses data for tracking.NSPrivacyTrackingDomains: domains that the app connects to for tracking. If the user hasn’t given tracking permission, the system blocks connections to them.NSPrivacyCollectedDataTypes: the types of data collected and what they’re used for.NSPrivacyAccessedAPITypes: which “required reason” APIs the app uses, and why.
Required reason APIs
Some ordinary-looking APIs could be used to fingerprint a device, so Apple requires an approved reason for using them. Since 1 May 2024, according to Apple’s upcoming requirements page, you can’t upload a new app or update to App Store Connect without declaring them, including those used by third-party SDKs inside your app.
The categories are user defaults, file timestamps, system boot time, disk space and active keyboards. Plenty of apps touch at least one: UserDefaults alone counts. A minimal manifest for an app that uses UserDefaults for its own settings, doesn’t track and collects no data looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyTrackingDomains</key>
<array/>
<key>NSPrivacyCollectedDataTypes</key>
<array/>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>CA92.1</string>
</array>
</dict>
</array>
</dict>
</plist>CA92.1 is the reason for reading and writing user defaults that only the app itself can access. If you share defaults with a widget through an App Group, the reason is 1C8F.1 instead. Each code has a precise meaning and some forbid sending the information off the device, so pick from Apple’s list of approved reasons rather than copying one from another project.
Third-party SDKs
Apple publishes a list of commonly used third-party SDKs that must include their own privacy manifest and, when included as a binary, a signature. Keep SDKs up to date so they carry current manifests, and check what each one collects: their declarations become part of your app’s privacy story.
Xcode can combine every manifest in your app into a privacy report: archive the app, then in the Organizer, right-click the archive and choose Generate Privacy Report. Use it when filling in the App Privacy section of App Store Connect, so the two match.
Rules that surprise people at review
Some guidelines catch teams out because they’re about business decisions rather than code:
- Account deletion (guideline 5.1.1(v)). If your app lets people create an account, it must also let them start deleting it from within the app. A link to an email address isn’t enough. Apple’s guidance is at Offering account deletion in your app.
- Sign in options (guideline 4.8). If you offer third-party or social login, such as Google or Facebook, you generally also need to offer an equivalent option that meets Apple’s privacy criteria, and Sign in with Apple does. Read the exceptions in the guideline itself.
- Digital purchases (guideline 3.1.1). Unlocking features or content inside the app generally has to use In-App Purchase. Physical goods and services used outside the app, such as a taxi ride or a restaurant order, don’t. Rules differ by region, for example in the EU and US storefronts, so check the current guidelines for where you sell.
- Minimum functionality (guideline 4.2). A website wrapped in an app, or an app with very little to do, can be rejected. Native features, offline use and real utility help.
- Accurate metadata (guideline 2.3). Screenshots and descriptions must reflect the app as it is.
- Regulated services. Apps in fields such as banking, healthcare, gambling or crypto may need to be submitted by the legal entity providing the service rather than by an individual or agency, according to Apple’s App Review page.
- EU trader status. Under the EU Digital Services Act, apps without verified trader status are removed from the EU App Store until it’s provided. You set this in App Store Connect.
Making the reviewer’s job easy
Apple’s App Review page states that over 40% of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information. Most of that is avoidable:
- Provide a working demo account in App Review Information if anything needs signing in, with any data the reviewer needs to see the main features.
- Write review notes explaining anything non-obvious: hardware the app works with, features behind a location, how to trigger a subscription screen.
- Remove placeholder content and test every link, including support and privacy policy URLs, which every app needs.
- Test on the latest iOS release on a real device before submitting.
Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours, so a rejection usually costs days rather than weeks. Days can still matter when a launch date is public. The launch process guide covers how to plan for it.
If you’re rejected
Read the message in App Store Connect carefully; it cites the guideline. Often a clarification in a reply, a better purpose string or an updated review note is all it takes. If you think the reviewer misunderstood the app, you can reply in App Store Connect, request a call with App Review, or, as a last step, appeal to the App Review Board. Be specific and polite; it works better than frustration.
Key takeaways
- Keep permission prompts, ATT, privacy manifests and App Store privacy details consistent with each other and with the app.
- Ask for permissions in context with clear purpose strings, and handle refusal gracefully.
- Declare required-reason APIs, including
UserDefaults, with the correct reason codes; check every SDK’s manifest. - Know the business rules early: account deletion, sign-in options, In-App Purchase, regulated services and EU trader status.
- Give reviewers a demo account and notes; completeness issues are the most common cause of delays.
If you’re preparing an app for its first submission, or dealing with a rejection you don’t understand, send me the details and I’ll help you work out what’s needed.
Written by Lee Johnson. Published 30 October 2026.