A new app can overwhelm people by asking for several permissions before they understand its value. It can also break later when a previously granted permission is removed. Ask the agency to connect every request to a real feature and design the denied path alongside the approved one.
Related service: Mobile application development- 01User starts the feature
- 02Explain necessary access
- 03Handle the system decision
- 04Continue or offer an alternative
SECTION 01
Ask for a feature-to-permission map
List camera capture, location check-in, notifications and any file access separately. Identify which requests can be avoided through a system picker or a narrower capability. The agency should explain why each requested permission exists and which screen uses it, including permissions introduced by third-party components.
Android's runtime-permission guidance recommends asking in context and handling denial gracefully. Device versions and platform behavior differ, so require tests for the supported operating systems rather than assuming one prompt flow works everywhere. The wording before a system prompt should describe the actual use, not pressure the user into accepting.
SECTION 02
Illustrative example: adding a service photo
A customer opens an app to view an appointment. No camera permission is needed. Later, they choose to attach a photo of the equipment. If camera access is denied, the app preserves the request form and offers the agreed alternative, such as selecting an existing image through a system interface or continuing without a photo when allowed.
If a photo is genuinely required, explain that requirement and provide a support route rather than repeatedly showing the same permission request. When the user changes permission in device settings and returns, the feature updates its state without discarding their draft. This example distinguishes task requirements from a blanket demand for access.
SECTION 03
Include revocation and partial access
Test first grant, initial denial, repeated denial, access changed in settings and returning from the background. Location may be approximate rather than precise; Android's location guidance distinguishes those modes. The app must communicate when available precision cannot support a specific action without pretending it knows more than it does.
At handoff, request the permission inventory, explanatory copy, denied-state screenshots and tested device matrix. Compare a narrower feature with one requiring persistent access. Fewer permissions can simplify onboarding, but only if the remaining workflow still serves the user's task and the product explains any resulting limitations honestly.
SECTION 04
Frequently asked questions
Should the app ask for all permissions at first launch?
Usually that obscures why access is needed. Connect requests to the relevant action unless a specific platform requirement or justified workflow dictates otherwise.
Can the app force users to enable permission?
It can explain a feature's requirement, but it should respect the decision and preserve unrelated functionality rather than repeatedly pressuring the user.
Do cross-platform apps avoid permission testing?
No. Shared code does not remove operating-system differences. Test the actual Android and iOS behavior in the supported release scope.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Request runtime permissionsAndroid Developers
- Location access and accuracyAndroid Developers
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy