Before app review: check Info.plist and AndroidManifest.xml permissions
Which release files to provide, how purpose-string and exported-component checks work, and what configuration reports can—and cannot—tell you about store review.
6 min read
A clean screenshot set does not tell you whether the release has a blank camera purpose string, a debugging entitlement, or an Android receiver without an explicit exported setting. Those details live in the configuration packaged with the app. Reviewing the right files makes the conversation about permissions more concrete.
In Releaseyour.App, open an app’s Releases tab and select Permission & configuration pre-review. You can use it before creating a release record. Files are parsed locally in your browser, and a report separates configuration issues from follow-ups that need context.
For iOS, start with the built Info.plist
Use Info.plist from the archived release app rather than assuming the project source is identical. Build settings can substitute the bundle ID and other values during compilation. A source placeholder such as $(PRODUCT_BUNDLE_IDENTIFIER) is a reason to inspect the built configuration, not evidence of a definite store violation.
- Find the release archive in Xcode Organizer and inspect its packaged app under Products/Applications.
- Provide the built Info.plist as XML. If it is binary, convert a copy with
plutil -convert xml1 -o Info.review.plist Info.plist. - Select the permission-using features this release actually requests: camera, microphone, photo access, location authorization, or the other supported options.
The feature selection matters. A missing purpose key cannot be discovered from a plist alone if the only evidence that the app uses that API is hidden in code. The checker can identify missing purpose text for a feature you selected; it cannot infer all behavior from the file.
Add privacy and entitlement context when you have it
You can also supply PrivacyInfo.xcprivacy and exported release-entitlements XML. The privacy checks inspect declared structure: expected types, non-empty reason and purpose arrays, and tracking declarations that need to agree with consent and store disclosures.
A reason code being present does not establish that it is an approved reason for this app’s use. Compare it with Apple’s current reference, the archive’s aggregated privacy report, and included SDK manifests. Entitlement findings likewise refer to the uploaded file; verify the actual signed distribution artifact and provisioning profile.
Missing optional files appear as coverage gaps. They do not turn into invented failures, and the report does not assert that every app must provide the same privacy or capability declarations.
For Android, use the merged release manifest
The source file in your app module can omit permissions added by libraries, resolved application IDs, and SDK settings. Choose readable AndroidManifest.xml from the release variant’s merged output or export a decoded XML view from Android Studio. A compiled binary manifest inside an APK is not the text format the checker accepts.
- Distribution settings: explicit debuggable or test-only values are highlighted for release preparation.
- Exported components: activities, services, and receivers with intent filters need explicit exported values under the applicable Android 12+ target-SDK rule. A normal exported launcher is distinguished from other external entry points.
- Permissions: sensitive or restricted declarations prompt runtime-consent, eligibility, or Play Console follow-ups. A declared permission is not automatically a policy violation.
- SDK context: the target API is shown with a link to current Play requirements. The report does not invent a timeless approval threshold.
Include network security XML if the manifest references it
Supplying the referenced network-security resource adds context for global and domain-specific cleartext exceptions and active user-certificate trust. Debug-only overrides are excluded from release trust findings, and nested domain rules respect child overrides.
If the resource is missing, the report says it was not assessed. A manifest flag alone does not establish what traffic the app sends or what the effective policy permits in every case.
Use the report as a review to-do list
Each finding includes evidence, a suggested next step, and official guidance. Download the JSON report if you want a record for the person fixing the configuration. Changing a file or the selected iOS features clears the previous result.
These checks do not inspect the binary, private SDK behavior, localized permission prompts, runtime consent, actual data flows, or store privacy answers. They do not calculate approval odds. Follow them with device testing and the store’s current requirements. See where configuration review fits into the complete release workflow.
Bring the whole release into focus
Start with a free tool, then bring versioned assets, every locale, pre-review findings, competitor observations, and your release checklist into one workspace.