Native Capabilities
A capability is a device permission compiled into the app. The platform knows thirteen, and each carries real consequences.
Where to find it
Architect Panel → Mobile Apps:
- Mobile Canvas — the app, its screens and its settings
- App Builds & Releases — building and submitting
- Mobile Devices — the devices that have installed it
The catalogue
- Camera — photos, video and barcode scanning.
- Photo library — choosing an existing photo instead of taking one.
- Microphone — audio notes.
- Location (while in use) — stamping records and showing them on a map.
- Location (always) — tracking with the app closed.
- Push, biometrics, files, contacts, calendar, NFC, Bluetooth and motion.
Each maps to specific iOS usage keys and Android permissions, and each names the components that need it.
Background location is a different application
It is deliberately separate from ordinary location, not a flag on it — because Apple treats it as a different kind of app. It requires written justification at review, produces recurring "this app has been using your location" prompts for the user, and is frequently refused outright.
Enable it only if the app genuinely cannot do its job otherwise. Turning on foreground location must never opt you into it by accident, which is why the two are separate.
Every capability needs a purpose string
The sentence the user sees when the permission is requested, and the one a reviewer reads. The platform supplies a sensible default for each, and you should replace it with something true of your app.
"This app requires camera access" is rejected. "Take photographs of work carried out and attach them to the job record" is approved, and it is also the honest answer to a user wondering why you are asking.
Ask for the narrowest thing
Photo library read rather than write. Location while in use rather than always. Each narrowing makes review easier and makes users more likely to agree.
Unused capabilities are a problem
A declared permission the app never uses is flagged at review as an unused permission. So capabilities you turned on to try something must be turned off again — and that means a rebuild.
Components are hidden without their capability
A component needing a capability the installed binary does not declare is omitted from what the app receives, rather than sent and failed.
That is deliberate: on a device, using an undeclared permission does not show an error — it terminates the app. Omitting the component is the only safe behaviour.
Turn one on, and you owe a rebuild
Both directions. Turning a capability on means the installed app cannot use it until rebuilt; turning one off means the installed app still declares it until rebuilt. The platform tells you which, and why.
Worked example
A field app declares camera, photo library, location while in use, push and biometrics — five capabilities, each with a purpose string describing the actual job. Background location was considered and rejected as unlikely to survive review for the benefit it offered.
Recommendations
- Write a real purpose string for every capability.
- Avoid background location unless the app cannot work without it.
- Turn off what you tried and rebuild.
- Ask for the narrowest permission that does the job.