Most iOS rejections in this area come from two preventable problems: screenshots that do not meet App Store Connect’s file, size, device, or accuracy rules, and privacy-sensitive APIs that lack a matching, specific purpose string in Info.plist. Correct every required device class, remove transparency, describe each data use plainly, and submit complete review information—including working credentials when the app requires an account.
What Apple checks before approving screenshots and permissions
App Review evaluates both the metadata customers see and the behavior of the binary they install. Screenshots must represent the shipped experience on the device family selected in App Store Connect. Permission prompts must explain the actual use of protected data or hardware. A mismatch in either area can make an otherwise functional app appear misleading, incomplete, or unsafe.
As an Amazon Associate I earn from qualifying purchases.
Apple’s review guidance says that permission requests should clearly and completely describe how an app will use user or usage data. Its Technical Q&A QA1937 also states that apps can be rejected when privacy-sensitive data is requested without a usage description. The requirement applies to APIs called by your own code and to APIs brought in by third-party SDKs.
Recommended Free Tools
Screenshot requirements that commonly cause rejection
Provide at least one valid image for every required device class
App Store Connect requires at least one screenshot and allows up to 10 screenshots for each device size. The exact device classes depend on the platforms and devices your app supports. An iPhone-only app has a different asset set from a universal iPhone-and-iPad app, and an iPad app must account for Apple’s current 13-inch iPad requirement.
#1 Best Overall
Apple’s current device table includes a largest iPhone portrait size of 1320 × 2868 pixels and a landscape size of 2868 × 1320 pixels. Other iPhone and iPad families use different dimensions, so do not apply those numbers to every upload. Check the current App Store Connect size table immediately before submission because Apple can add or change required classes.
When App Store Connect accepts a higher-resolution asset, it may scale that screenshot for smaller sizes. Supplying the largest accepted size can therefore reduce duplicate exports, but it does not remove the obligation to provide screenshots for every required platform or device family shown in your product page.
Use an accepted format with no transparency
- Accepted file types are JPEG, JPG, and PNG.
- Images must not contain an alpha channel or transparent pixels. Export a flattened image with an opaque background.
- Verify the pixel dimensions, orientation, and color profile after export rather than trusting the design tool’s canvas label.
- Upload the screenshot to the matching device type in App Store Connect; an iPad image should not be assigned to an iPhone slot.
Make every frame truthful to the submitted build
Screenshots should communicate the app’s value and functionality without implying features that are unavailable, restricted to another region, or removed from the current binary. Stale marketing art, an old navigation flow, fake data that suggests a capability the app does not provide, or a device frame that does not match the selected class can all create a review risk.
Keep screenshots, the written description, and preview assets synchronized whenever the core experience changes. Apple’s metadata guidance is aimed at ensuring customers know what they are getting; a screenshot that advertises a retired feature undermines that requirement even if the image technically meets the pixel specification.
Use the first screenshots to explain the main use case
Up to 10 screenshots may be displayed. When an app preview is not present, the first one to three images can appear in search results, so those opening frames should show the primary task and outcome rather than a secondary settings screen. Put explanatory overlay text inside the image only when it remains accurate, legible, and consistent with the interface shown.
A reliable screenshot preparation workflow
- List supported destinations. Record whether the build supports iPhone, iPad, or both, and note any platform-specific functionality. Use that list to identify every required App Store Connect device class.
- Capture the shipped UI. Use a release-candidate build with production navigation, current copy, and representative data. Do not capture from a prototype or an older TestFlight build.
- Export at the required pixels. Match Apple’s current table for each class and orientation you plan to upload. If you rely on scaling from a larger accepted asset, verify the resulting preview in App Store Connect.
- Flatten and inspect files. Confirm JPEG, JPG, or PNG format, an opaque background, correct orientation, and exact dimensions. A file can look correct while still carrying an alpha channel.
- Check factual accuracy. Compare every visible control, label, plan, entitlement, and feature with the binary that reviewers will download. Remove region-specific claims unless the same availability is clear in the listing.
- Order for comprehension. Place the primary value proposition in the first screenshot, then show the normal flow: starting action, meaningful result, and useful supporting features.
- Review the listing as a customer. Read the description and view screenshots together. Resolve contradictions before submitting the build.
Permission descriptions: what belongs in Info.plist
Every protected-resource API used by the app needs the exact purpose key associated with that API. The value is the sentence shown to a user in Apple’s authorization alert. A missing key, an incorrect key, or a key whose wording does not explain the real use can lead to rejection or a confusing permission prompt.
Use the API-specific key, not a generic privacy message. The following are common examples; confirm the key required by the framework and API in the SDK version you ship.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →| Resource or capability | Common purpose key | What the sentence should explain |
|---|---|---|
| Camera | NSCameraUsageDescription |
What the camera captures and the feature that uses the capture. |
| Microphone | NSMicrophoneUsageDescription |
When audio is recorded and what the recording enables. |
| Photo Library read access | NSPhotoLibraryUsageDescription |
Why the app needs to select or read the user’s photos. |
| Photo Library add-only access | NSPhotoLibraryAddUsageDescription |
Why the app saves images or video to the library. |
| Location while in use | NSLocationWhenInUseUsageDescription |
Which active feature uses location and when it operates. |
| Location always and in use | NSLocationAlwaysAndWhenInUseUsageDescription |
Why background or continuous location is essential, not merely convenient. |
| Bluetooth | NSBluetoothAlwaysUsageDescription |
Which nearby accessory or interaction requires Bluetooth. |
| Contacts | NSContactsUsageDescription |
What contact information is selected and for which user action. |
| Speech recognition | NSSpeechRecognitionUsageDescription |
How spoken words are converted into text or commands. |
| Motion and fitness | NSMotionUsageDescription |
What motion measurement powers in the app. |
| Face ID | NSFaceIDUsageDescription |
What signing-in or unlocking action Face ID protects. |
| App tracking | NSUserTrackingUsageDescription |
Why tracking permission is requested and the purpose of the identifier. |
Health, calendar, reminders, media, and other protected frameworks also have their own keys. Do not copy a key from an unrelated API. Build a permission inventory from the frameworks you call, then verify the exact key name and entitlement requirements for the deployment target you submit.
How to write a purpose string Apple can approve
Use a short, concrete sentence
Apple’s Human Interface Guidelines recommend copy that clearly describes how the app uses the requested ability, data, or resource. Write in sentence case, use active voice, identify the action, state the user benefit, and end with a period. The sentence should make sense without the app’s marketing copy.
A weak example identified by Apple is: "Microphone access is needed for a better experience." It does not say what is recorded or why. A stronger description is: "The app records during the night to detect snoring sounds." That wording names the activity and the result.
Match the sentence to the moment of use
Request access when the user starts the feature that needs it, not immediately at first launch unless the app genuinely requires the resource to function. A camera prompt shown while the user taps Scan has an understandable context; the same prompt before any camera feature is visible can feel unexplained.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsIf the user declines, provide sensible fallback behavior. Let a user choose a file instead of taking a photo, enter a value manually instead of sharing location, or continue in a limited mode when that is technically possible. Do not repeatedly interrupt the user or imply that permission is mandatory when the feature is optional.
Rank #4
Do not pressure users with a pre-permission screen
A custom explanation screen can be useful when it simply prepares the user for a system prompt, but it must not pressure the decision. Avoid incentives, threats, an imitation of Apple’s alert, an image of the alert, or annotations placed behind the system alert to steer the tap. Apple identifies those patterns as potential rejection causes.
Third-party SDKs can create the same rejection
App Review checks privacy-sensitive data access regardless of whether the call appears in your source files or in a dependency. An analytics, advertising, sign-in, camera, voice, health, or device-connectivity SDK can invoke a protected API on its own initialization path. If the corresponding purpose key is absent, the app can fail review even when your feature never visibly uses that resource.
- Generate a complete dependency list, including binary frameworks and transitive packages.
- Search application code and SDK documentation for protected-resource APIs and privacy manifests.
- Map each API to the exact
Info.plistkey and a sentence describing the user-visible purpose. - Remove unused SDK modules or disable optional capabilities that create an unnecessary permission request.
- Test a clean install so first-run initialization follows the same path a reviewer will see.
- Inspect the archive and the final exported app, not only the debug target’s plist.
When an SDK’s behavior is unclear, ask its maintainer which APIs it calls and under what conditions. A purpose string should describe the real behavior; adding a vague key merely to silence a build warning does not satisfy review.
Submission information that prevents an incomplete-review rejection
Permission and screenshot fixes are not enough if the review package omits information Apple needs to exercise the app. Apple’s App Review Help warns that incomplete submissions will be rejected. In App Store Connect, provide the following where applicable:
- The app concept, principal features, intended audience, and business model.
- For an update, a concise explanation of what functionality changed.
- Working demo credentials, including any one-time-code or seeded account procedure required to sign in.
- The devices and operating-system versions on which the submitted build was tested.
- External services, hardware, subscriptions, or server environments required to reach a feature.
- Regional differences, account restrictions, age gates, or content that reviewers will not see in every territory.
- Authorization letters, regulated-field documentation, or other records required for the app’s category.
- Review notes that explain non-obvious navigation, test data, and how to trigger permission-dependent features.
Test the credentials and external endpoints immediately before submission. If a reviewer cannot sign in, cannot reach the feature described by a screenshot, or encounters a regional block with no explanation, a technically correct binary can still be rejected.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Manual remediation versus automation or consulting
Teams often decide whether to fix these issues in-house or use an asset-management, validation, or review-preparation service. The useful comparison is coverage and verification, not a promise of approval.
| Decision point | Manual process | Automation or consulting process |
|---|---|---|
| Device-size coverage | Developers and designers maintain the Apple size matrix and upload each class. | A tool or specialist may generate and validate variants across device sizes and localizations; confirm which classes are actually supported. |
| File and pixel validation | Inspect exports with image tools and App Store Connect feedback. | Automated checks can detect format, dimensions, orientation, and alpha-channel errors before upload. |
| Stale or misleading UI | Compare each frame with the release candidate during a checklist review. | Reviewers may flag visible differences, but human confirmation is still required because visual automation cannot establish every entitlement or regional rule. |
| Privacy API inventory | Search source, build settings, and dependency documentation. | Scanners can identify first- and third-party API usage; validate findings against runtime behavior and the final archive. |
| Purpose-string drafts | Engineers and product writers describe the exact user action. | A service may draft wording, but a developer must correct generic language and confirm that it matches the feature. |
| Review package | Staff assemble credentials, test devices, notes, and documents in App Store Connect. | Consultants may package and audit these materials; you remain responsible for working accounts and truthful declarations. |
Whichever approach you choose, retain a human approval step. No validator can infer that a screenshot’s claim is commercially or regionally accurate from pixels alone, and no generated sentence can replace knowledge of when your app actually records, stores, or transmits data.
Quick Recap
Rejection symptoms and targeted fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Screenshot upload is rejected | Wrong extension, dimensions, orientation, or an alpha channel. | Re-export as JPEG, JPG, or opaque PNG at the exact device-class dimensions. |
| Screenshot passes upload but metadata is questioned | The frame shows an old flow, unavailable feature, or mismatched device. | Capture the current release build and assign it to the correct device type. |
| App crashes or is rejected when opening a feature | A protected API is used without its purpose key. | Inventory direct and SDK calls, add the exact key, and test a clean install. |
| The permission alert is considered vague | The string says only "better experience" or another generic benefit. | Name the action, timing, data, and user-facing result in one active sentence. |
| Reviewer cannot complete the test | Credentials, external service details, or regional instructions are missing. | Supply working access, setup steps, test environment details, and review notes. |
| Users deny a permission immediately | The prompt appears before the feature context or offers no fallback. | Request at the point of need, explain the concrete use, and support a limited alternative. |
Final pre-submission checklist
- At least one screenshot exists for every required platform and device class, with no more than 10 per size.
- Every image is JPEG, JPG, or PNG, has no transparency, and matches Apple’s current pixel table.
- The first one to three images communicate the app’s primary use case.
- All visible screens, claims, plans, and controls match the release build and supported regions.
- Every protected-resource API, including SDK calls, has the exact corresponding purpose key.
- Each purpose string is brief, specific, active, complete, and ends with a period.
- Permission requests occur in feature context and have a reasonable denial fallback.
- No custom pre-permission screen pressures the user or imitates Apple’s system alert.
- Demo credentials work, external services are reachable, and tested devices and OS versions are documented.
- Regional differences, changed functionality, review notes, and required authorization documents are included.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
