What this task does

Before iOS lets your app touch the camera, the user’s location, their photo library, or their contacts, it shows the user a one-time system prompt asking permission. That prompt needs a short sentence — written by you — explaining why your app wants access. Apple calls these usage descriptions, and they’re not optional: a build that touches one of these features without a usage description string gets rejected during App Store review.

MAM Suite gives you one place to enter all four strings — the iOS Permission Descriptions panel on the Publish page — and ships them into your app’s Info.plist (as NS*UsageDescription entries) automatically when the build runs. Here’s what to write, and where it goes.

This only applies to iOS. Android handles runtime permissions its own way and doesn’t use these strings.

Before you start

• You are a site admin with access to the MAM Suite Publish page (requires the manage_options capability).
• You know which device features your app actually uses. If a feature is turned on for any user role, you should write a description for it. (See Which messages do I need? below.)
• Have your app’s name and purpose in mind — good usage strings are specific to your app, not generic.

The four fields

The iOS Permission Descriptions panel gives you one text box per permission. Filling each one in is optional as far as the form is concerned, but Apple requires it for any feature your app actually uses.

Each field starts out pre-filled with a sensible default — keep it, tweak it, or replace it outright. Here’s what ships today:

• Camera — “This app uses the camera to allow you to upload photos and images.”
• Location When In Use — “Your location is used to show nearby content and improve local results.”
• Photos — “Photo access is used to let you upload images to your profile or listings.”
• Contacts — “Contacts access is used only when you choose to invite contacts.”

These defaults are deliberately generic — a starting point, not a finish line. Apple frequently rejects builds with vague usage strings, so it’s worth taking a minute to make yours specific to your app.

Steps

1. In WordPress admin, open the Mobile App Mgr → Publish App page.
2. Scroll to the iOS Permission Descriptions panel.
3. For each feature your app uses, edit the text box to explain — in plain language — why your app needs that access and what’s in it for the user.
4. Only leave the default text in place if it genuinely describes your app. If you’re not sure, rewrite it.
5. Click Save App Settings at the bottom of the page. Your messages are saved, and you’ll see them again the next time you open this page.

That’s all there is to entering the copy. These strings get picked up automatically the next time you submit a publish request — there’s nowhere else you need to paste them.

Which messages do I need?

Write a description for every device feature your app can actually trigger. In MAM Suite, camera and GPS are tied to role-level app settings (under your app’s general settings) — that’s how the build process knows which features are turned on. As a rule of thumb:

• Camera — fill this in if any role can take a photo in-app (profile photos, uploads, scanning).
• Location When In Use (GPS) — fill this in if any role uses location features (“near me”, maps, location-gated content). MAM’s GPS/geofilter features rely on this.
• Photos — fill this in if users can pick an existing image from their library.
• Contacts — fill this in only if your app reads the address book (rare; e.g. an “invite contacts” flow).

If a feature is off for every role, it’s fine to leave its description on the default — iOS will never ask, so it never shows. But there’s no harm in filling it in anyway, and that’s the safer bet if you’re unsure whether a feature is enabled.

Not sure which features are turned on? Check the app’s general settings for the camera and GPS toggles, or ask whoever configured the app’s roles.

Writing strings Apple will accept

Apple’s review team reads these strings the way a real user would. Strings that are empty, one word, or obviously copy-pasted boilerplate are a common reason for rejection. Good usage descriptions:

• Name the benefit to the user, not just the technical fact. Prefer “Allow access so you can attach a photo to your service request” over “The app uses the camera.”
• Are specific to your app. Mention the actual feature (“…to scan your membership card”, “…to show events near you”).
• Are a complete sentence. End with a period.
• Avoid jargon and developer terms. No “API”, “SDK”, or option keys — this is end-user copy.
• Don’t over-promise. Only describe access the app genuinely uses.

Example rewrites:

What happens behind the scenes

You don’t need any of this to use the feature, but here’s how it connects behind the scenes:

1. When you save the Publish page, each message gets stored as a WordPress option (ios_permission_camera, ios_permission_location_when_in_use, ios_permission_photos, ios_permission_contacts) — the save handler sanitizes the text but allows basic formatting.
2. When you kick off a build, the MAM build process reads these options and folds them into the settings payload sent to the build pipeline (as camera_message, gps_message, photos_message, and contacts_message).
3. The pipeline writes them into your app’s iOS Info.plist as the matching NS*UsageDescription entries (camera, location-when-in-use, photo library, contacts).
4. iOS shows that exact text in the permission prompt the first time the app requests access.

Because the strings get baked into the binary at build time, editing them here only affects builds you submit afterward — a build that’s already live keeps whatever strings it shipped with. So if you want to change the wording in a live app, edit the message here and submit a new build.

Verify it worked

• After saving, reload the Publish page — your edited text should still be in each box.
• After you submit a new build and install it (via TestFlight), trigger the relevant feature (e.g. tap something that opens the camera). The iOS permission prompt should show your exact wording.
• If App Store review rejects the build citing a “purpose string” or “usage description,” revisit these fields, make them more specific to your app, and resubmit.

Troubleshooting

• Apple rejected the build for a missing/vague purpose string. Edit the named permission’s box to be specific to your app (see Writing strings Apple will accept), save, and submit a new build.
• The prompt still shows old wording after editing. The change only ships with a new build. Submit a fresh publish request, then install the resulting TestFlight/App Store build.
• A permission prompt never appears. That feature may be disabled for the user’s role. iOS only prompts when the app actually requests access, so the usage string is never shown if the feature is off.

Verification

This article was last verified against:

• mam-main — includes/publish-app/app-submit.php (render_ios_permissions(), get_default_ios_permissions(), save handler)
• mam-main — includes/publish-app/mam-app-publishing.php (fastlane_fetch_settings() payload mapping, feature flags derived from role general-settings)
• mam-main/user_docs/02f-recipe-publish-app-ios-android.md

Re-verify if the iOS Permission Descriptions panel adds/removes a field, the ios_permission_* option keys change, the default strings change, or the build-payload key names (camera_message, gps_message, photos_message, contacts_message) change.

Related articles

• Recipe: Publish your app to iOS and Android
• Hook: mam_fastlane_settings (inject custom build-time config / Info.plist entries)
• App Setting Reference: Use Camera
• App Setting Reference: Use GPS