Info.plist permission strings
Tick the protected resources your app asks for (camera, photos, location, contacts, calendars, Bluetooth, local network, Face ID, HealthKit, tracking and the rest) and get every NS…UsageDescription key you need, each with a one-sentence purpose string that names your app and your feature, in English and Chinese. Copy it as Info.plist lines, an InfoPlist.xcstrings catalog or InfoPlist.strings files. Or paste your Info.plist to find missing pairs, placeholders, pushy wording and deprecated keys. Nothing is uploaded.
Key names, platforms and deprecations are copied from Apple's Protected resources documentation, checked on 2026-10-30.
Your app
Used at the start of each sentence. Leave blank for "This app" / "本 App".
What your app uses
Tick only what your app really asks for. Each one adds a key; asking for less is more likely to be allowed and is what App Review guideline 5.1.1 (iii) asks for.
0 selected
Your strings
Tick at least one item to see the strings.
How it works
- •Every key comes from Apple's Protected resources documentation, with the platforms and versions Apple lists for it. Keys Apple marks deprecated (such as NSCalendarsUsageDescription, replaced in iOS 17) are flagged, not offered, unless you say you support older systems.
- •Each sentence follows Apple's advice for purpose strings: one complete sentence that says what the access is for. It starts with your app's name and ends with the feature you type, so a reader sees the benefit, for example "Trailmate uses the camera so you can photograph trail signs."
- •Some keys come in pairs. Ticking Location always also adds the When In Use key, because Core Location shows the When In Use prompt first. The older-systems option adds the pre-iOS 17 calendar and reminder keys with the same sentence.
- •The Info.plist lines are escaped XML with tab indentation, like Xcode writes. The string catalog has English and Simplified Chinese for each key; the .strings files are one per language.
- •The checker reads your Info.plist in this page and flags: empty strings, placeholders such as TODO, strings under about one sentence, vague ones such as "This app needs your camera", pressure such as "won't work unless", strings over 4,000 bytes, misspelt or unknown keys, deprecated keys, and missing partners such as Always location without When In Use.
What it does not do
- •It does not scan your code to find which permissions you request. You tick them; a search for AVCaptureDevice, CLLocationManager, PHPhotoLibrary, CNContactStore and EKEventStore is a good start.
- •It cannot know whether your sentence is true. Write what your app actually does with the access; App Review compares the string with the app.
- •Its wording checks are patterns, not judgement. A clean result does not guarantee approval, and a warning may be fine in context.
- •It does not handle the dictionary keys, such as NSLocationTemporaryUsageDescriptionDictionary or NSIdentityUsageDescriptionDictionary, or entitlements that some resources also need (HealthKit, HomeKit, NFC, Siri).
- •Translations other than English and Chinese are up to you. The string catalog is ready for more languages in Xcode.
- •It reads XML property lists only. Convert a binary one first with plutil -convert xml1.
Questions
- What makes a good purpose string?
- Apple asks for an accurate, specific explanation, typically one complete sentence: what you access, what you do with it, and how that helps the person. "Trailmate uses your location while you are using the app to show trails near you" is good; "This app needs your location" is not. App Review guideline 5.1.1 (ii) asks that purpose strings clearly and completely describe your use of the data.
- Why was my app rejected for its purpose string under 5.1.1?
- Usually because the string is vague ("needs access to the camera"), is a placeholder, or does not match what the app does. Guideline 5.1.1 (iv) also rejects pressure: apps must not manipulate, trick or force people to consent, so avoid lines like "the app won't work unless you allow this" and offer another way when people decline, such as typing an address instead of sharing location.
- Do I need both location keys?
- For Always access on iOS, yes. Add NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription: Core Location first asks for When In Use with that string and later asks to upgrade to Always. If you only need location while the app is open, use just the When In Use key. macOS apps use NSLocationUsageDescription.
- NSPhotoLibraryUsageDescription or NSPhotoLibraryAddUsageDescription?
- If you only save pictures, use the add-only key. If people just pick photos, the system photo picker runs outside your app and needs no permission at all, which is what guideline 5.1.1 (iii) recommends. Use NSPhotoLibraryUsageDescription only when your app reads the library itself.
- Which calendar key do I use since iOS 17?
- NSCalendarsFullAccessUsageDescription to read and write events, or NSCalendarsWriteOnlyAccessUsageDescription to only add them. NSCalendarsUsageDescription is deprecated; keep it alongside the new key only if your app also runs on iOS 16 or earlier. If you only show the system event editor on iOS 17 or later, you need no calendar access.
- How do I translate purpose strings?
- Add an InfoPlist.xcstrings string catalog to the target, or InfoPlist.strings files in each .lproj folder for older projects. The key stays in Info.plist with your development language's sentence; the catalog supplies the other languages. This page writes English and Simplified Chinese for you.