If your app uses the camera, most review rejections come from a small set of avoidable mistakes rather than anything deep.
iOS:
- NSCameraUsageDescription is required, and the string has to say what you use the camera for in plain language. "This app requires camera access" gets rejected. "We use the camera to place furniture in your room" does not.
- The same applies to any other permission you request. Vague purpose strings are the single most common cause.
- Do not ask for a permission you do not use. Reviewers check.
- Ask at the moment it is needed, not on first launch before the user knows what the app is.
Android:
- Declare only the permissions you actually use, and expect to justify anything sensitive.
- If you target AR Core devices, be explicit in the manifest about whether AR is required or optional, because it changes who can install you.
Both:
- Have a working privacy policy at a real URL before you submit, not after.
- Be accurate on the data safety and privacy questionnaire. Getting this wrong is slower to fix than a code rejection because it is a trust issue.
- Test on a device where the user denies the permission. An app that crashes or hangs when camera access is refused fails review, and it is the single most common thing we see missed.
That last one catches a lot of teams. The happy path gets tested a hundred times and the refusal path never once.
Anyone hit a rejection reason not on this list? Worth collecting them here.
iOS:
- NSCameraUsageDescription is required, and the string has to say what you use the camera for in plain language. "This app requires camera access" gets rejected. "We use the camera to place furniture in your room" does not.
- The same applies to any other permission you request. Vague purpose strings are the single most common cause.
- Do not ask for a permission you do not use. Reviewers check.
- Ask at the moment it is needed, not on first launch before the user knows what the app is.
Android:
- Declare only the permissions you actually use, and expect to justify anything sensitive.
- If you target AR Core devices, be explicit in the manifest about whether AR is required or optional, because it changes who can install you.
Both:
- Have a working privacy policy at a real URL before you submit, not after.
- Be accurate on the data safety and privacy questionnaire. Getting this wrong is slower to fix than a code rejection because it is a trust issue.
- Test on a device where the user denies the permission. An app that crashes or hangs when camera access is refused fails review, and it is the single most common thing we see missed.
That last one catches a lot of teams. The happy path gets tested a hundred times and the refusal path never once.
Anyone hit a rejection reason not on this list? Worth collecting them here.