Security
Permission prompts that survive store review — and user trust
During security posture reviews we spend more time on permission honesty than on exotic attack paths. Store reviewers and everyday users both notice when an app asks for location, camera, or contacts without a clear reason tied to the next action.
Ask when the feature needs it
Requesting every permission on first launch still appears in release candidates. It also fails common store expectations. Tie the system dialog to a user action: attaching a photo, sharing a location pin, or importing a contact for a transfer.
Explain before the system dialog
A short pre-prompt screen in Thai and English stating what the permission enables — and what still works if declined — reduces accidental denials. That screen is also evidence for reviewers that the ask is purposeful.
Plan for denial
Apps that crash or dead-end after a “Don’t Allow” choice create both usability and trust findings. Offer a path to continue with reduced capability, and a clear route to Settings when the user later changes their mind.
Match the privacy questionnaire
Release readiness work often catches mismatches: the binary requests tracking-related identifiers while the questionnaire says otherwise, or screenshots hide a permission that appears on first run. Align those materials before submission day.
If you want a structured pass on these items, our security posture review and full release readiness audit both cover permission timing and copy.