Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Most screenshot and privacy-description rejections have a specific, fixable cause: a missing or invalid asset, a screenshot that does not represent the shipped build, or an Info.plist purpose string that is absent, vague, or incomplete. App Store Connect requires at least one valid screenshot for every required platform and device class, while every privacy-sensitive API used by your code or by an embedded SDK needs a matching, user-facing explanation.
Fix the issue by checking assets against Apple’s current device table, rebuilding screenshots from the release candidate, inventorying protected-resource APIs in all dependencies, and submitting complete review information. The steps below explain what reviewers look for, what belongs in Info.plist, and how to recover from the common rejection messages.
Start with the rejection category
Read the Resolution Center message literally before changing anything. Screenshot problems and privacy-description problems often appear together, but they require different evidence in the next submission.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Reviewer concern | What it usually means | First check |
|---|---|---|
| Missing or invalid screenshots | An asset is absent, uses an unsupported format, contains transparency, or is missing for a required device class. | App Store Connect asset slots, file type, alpha channel, and pixel dimensions. |
| Misleading or outdated metadata | The image shows a feature, layout, device, or text that the uploaded build does not provide. | Compare every frame with the release candidate and current description. |
| Missing usage description | A protected-resource API is called without its required purpose key. | Search application code and every SDK for privacy-sensitive API calls, then inspect the archived app’s Info.plist. |
| Unclear purpose string | The key exists, but the wording does not explain the action and benefit to the user. | Rewrite it as a short, specific sentence in active voice. |
| Incomplete submission | Reviewers cannot test the app or understand its services, account requirements, or regulated features. | Review notes, demo credentials, tested devices and OS versions, external services, and required documents. |
Screenshot requirements that trigger rejections
Provide one valid image for each required device class
App Store Connect requires at least one screenshot and permits up to 10 screenshots per device size. You must supply assets for each platform and device class that Apple requests for the app’s declared support. Requirements vary by iPhone, iPad, Mac, Apple TV, Apple Watch, and other supported platforms. A single image is not automatically sufficient for every class.
#1 Best Overall
Apple’s current submission guidance includes an iPhone class with the Dynamic Island and, for iPad apps, a 13-inch iPad requirement. Check the current App Store Connect screenshot table immediately before uploading because device classes and required dimensions can change. If Apple accepts a higher-resolution asset for a class, that asset may be scaled to populate smaller sizes; do not assume that scaling eliminates a required class or permits arbitrary dimensions.
Use an accepted file type with no transparency
Accepted screenshot files are JPEG, JPG, or PNG. They cannot contain an alpha channel or transparency. A PNG that looks opaque can still carry an alpha channel from a design tool or export preset and fail validation. Flatten the image against an opaque background, export again, and inspect the file properties before uploading.
- Use the exact pixel dimensions listed for the selected device class.
- Keep the orientation consistent with the asset: portrait files must be portrait and landscape files landscape.
- Do not rely on a filename to identify a device; select the matching device type in App Store Connect.
- Open the final files outside the design tool to verify that no transparent pixels remain.
Example: the largest current iPhone class
Apple lists 1320 × 2868 pixels for portrait and 2868 × 1320 pixels for landscape for the largest current iPhone screenshot class. Those numbers apply to that class only; other iPhone and iPad families use different dimensions. Treat them as an example of the precision required, not as a universal canvas size.
Make every frame truthful to the shipped build
Reviewers expect screenshots to communicate the app’s real value and functionality. A frame can be rejected even when its dimensions are perfect if it shows a feature removed from the build, a navigation path users cannot reach, placeholder data presented as live functionality, or controls that belong to another device type.
Capture from the exact release candidate you submit. If the build changes after capture, regenerate the affected images. Keep screenshots, the app description, and preview assets synchronized whenever a core feature, onboarding flow, subscription offer, or supported device changes.
Order the opening screenshots for search and review
Up to 10 screenshots may be displayed. When no app preview is available, the first one to three can appear in search results. Put the primary use case and clearest value proposition first rather than beginning with a settings page or a secondary feature. Overlay copy must remain accurate, legible, and consistent with the current interface.
Rank #3
Prepare and upload screenshots step by step
- Identify the submission matrix. List every platform and device class enabled by the app record, including the iPhone Dynamic Island class and the 13-inch iPad class when applicable.
- Read Apple’s current dimension table. Record the required pixel width, height, and orientation for each class. Do not reuse dimensions from an older release without checking them.
- Capture the release candidate. Use the build that will be submitted, with representative data and the same localization shown in the metadata.
- Choose the strongest sequence. Put the main job-to-be-done first, then show the shortest path to meaningful functionality. Include no feature that requires an unavailable account, server, or entitlement unless the reviewer can access it.
- Export as JPEG, JPG, or PNG. Flatten transparency and remove alpha channels. Preserve the required pixel dimensions rather than allowing an export tool to resize automatically.
- Perform a visual and technical check. Confirm orientation, dimensions, readable text, truthful controls, and the absence of simulator chrome or unrelated personal data.
- Upload to the matching slot. Select the correct device type in App Store Connect and verify that every required class has at least one asset before submitting.
- Recheck after metadata edits. A description or feature change can make a previously accurate screenshot misleading, so review the entire set whenever metadata changes.
What belongs in Info.plist for privacy-sensitive APIs
Match each API to its purpose key
Every protected-resource API that your app uses needs the exact Info.plist purpose key required for that API. Apple’s review checks include calls made through third-party libraries, not only code in your own target. A dependency that accesses the microphone, camera, location, contacts, photos, Bluetooth, motion data, speech recognition, health data, or another protected resource can therefore cause rejection if its key is missing.
Typical key names include NSCameraUsageDescription, NSMicrophoneUsageDescription, NSLocationWhenInUseUsageDescription, NSPhotoLibraryUsageDescription, NSContactsUsageDescription, NSFaceIDUsageDescription, NSSpeechRecognitionUsageDescription, NSBluetoothAlwaysUsageDescription, NSMotionUsageDescription, and the appropriate health-data usage keys. These examples are not a substitute for checking the API’s current Apple documentation: use the key that exactly matches the resource and access mode in the submitted binary.
Inventory your own code and SDKs
- Search source code for protected-resource frameworks and permission-request methods.
- Inspect package manifests, binary frameworks, plugins, analytics components, advertising modules, and other SDKs for the same APIs.
- Review the release archive’s effective
Info.plist, not only the plist in a development target. Build settings, configuration files, and target inheritance can change the final value. - Map every API to one purpose key and document which feature triggers the request.
- Test a clean install on each supported OS family so the system prompt appears with the intended text.
Apple’s Technical Q&A QA1937 states that App Review rejects requests for privacy-sensitive data without a usage description, including access originating in third-party libraries. Removing a visible permission prompt is not enough if a linked SDK still invokes the protected API.
Write a complete, specific purpose string
Apple’s Human Interface Guidelines recommend copy that clearly describes how the app uses the requested ability, data, or resource. A good string is brief, specific, written in sentence case, uses active voice, identifies the action and benefit, and ends with a period.
| Weak wording | Why it fails | More useful wording |
|---|---|---|
| “Microphone access is needed for a better experience.” | It does not say what the app records or why. | “The app records during the night to detect snoring sounds.” |
| “We need your photos.” | It does not identify the operation or user benefit. | “The app saves your selected photos to create a private travel journal.” |
| “Location is required.” | It omits when location is read and what the user receives. | “The app uses your location while you navigate to show nearby transit stops.” |
The wording must describe the actual implementation. Do not claim that data stays on the device, is encrypted, or is never shared unless that is true for the submitted build and its services. If the feature works only while the app is in use, say so; if background access is requested, explain the background purpose rather than borrowing an in-use explanation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Request permission at the moment of need
Ask for access when the user starts the feature that needs it, not immediately at launch without context. Before the system alert appears, explain the task in your normal interface using accurate, non-coercive copy. If the user declines, provide sensible fallback behavior: let them continue without the optional feature, choose an alternative input, or explain how to enable access later in Settings.
Avoid coercive pre-permission screens
Apple can reject a custom screen that pressures the user with incentives, imitates the system alert, displays an alert image, or places annotations behind the system alert. A pre-permission explanation may clarify the feature, but it must not manipulate the choice or make the custom screen look like an Apple prompt. Use the real system alert, with the purpose string doing the essential explanation.
Submission information reviewers need
Apple says incomplete submissions will be rejected. A technically correct binary and valid screenshots can still fail if the reviewer cannot reach the core experience or lacks the context needed to test it.
- App concept and audience: State what the app does, who uses it, and the primary workflow.
- Feature map: Identify new or changed functionality for an update, including features hidden behind account creation or subscriptions.
- Demo credentials: Supply a working review account, password, one-time-code instructions, or another approved test path when sign-in is required. Explain any role or entitlement the account needs.
- Test matrix: List the devices and operating-system versions on which you tested the submitted build.
- External services: Name services required to operate the app and explain how the reviewer can reach them. Include regional differences, test servers, and setup steps when relevant.
- Regulated or restricted features: Attach required authorization, licensing, medical, financial, gambling, identity, or other supporting documents when the feature falls into a regulated category.
- Review notes: Give concise navigation steps to the feature under review, including any gesture, seed data, hardware, or timing requirement.
Do not use review notes to excuse a broken login, unavailable backend, or missing permission explanation. Notes help a reviewer test a working feature; they do not replace the required metadata or an accessible build.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Diagnose common rejection messages
“Missing screenshots” or an empty device slot
- Confirm that at least one image is uploaded for every required platform and device class.
- Check that the asset is attached to the correct device selector rather than another size with a similar name.
- Verify the file extension and pixel dimensions after export, not only inside the design project.
- Replace PNGs containing an alpha channel with flattened files.
“Invalid screenshot dimensions”
- Compare the measured pixel width and height with Apple’s current table for the selected class.
- Check for an accidental resize during compression, localization, or upload.
- Ensure the orientation matches the dimensions and the device shown.
- If using a higher-resolution asset intended to scale to smaller sizes, verify that Apple accepts that source size for the target class instead of assuming it will.
“Misleading screenshots” or inaccurate metadata
- Install the exact submitted build and follow every path shown in the images.
- Remove retired buttons, unreleased screens, fake metrics, and promotional claims that the app cannot deliver.
- Update screenshots when a server-driven feature, subscription screen, or onboarding flow changed without a binary change.
- Make the selected device and orientation match the actual interface shown.
“Missing purpose string”
- Identify the API named by the rejection and add its exact usage key to the target that ships.
- Search dependencies for the same API; an SDK can trigger the rejection even when your own source never requests permission directly.
- Archive again, inspect the built plist, and test a fresh install to confirm the prompt appears.
“Purpose string does not explain use”
- Replace generic benefits such as “better experience,” “improve service,” or “required for functionality.”
- Name the operation, timing, and user benefit in one plain sentence.
- Align the sentence with the actual data flow, including background access, uploads, sharing, or retention where those affect the user’s decision.
Manual remediation versus automation or consulting
Teams can repair these issues manually or use an asset-management, validation, or review-preparation service. The right choice depends on release frequency, platform count, localization count, and the number of SDKs in the dependency graph.
| Decision axis | Manual process | Automation or consulting process |
|---|---|---|
| Device-size and localization coverage | Engineers and designers maintain a checklist and export each variant. | A pipeline or specialist can generate, organize, and audit variants across device classes and locales. |
| File-format and dimension validation | Each file is checked with image metadata tools and App Store Connect validation. | Automated rules can flag unsupported formats, alpha channels, orientation, and pixel-size mismatches before upload. |
| Stale or misleading UI detection | Reviewers compare captures with the release candidate and metadata by hand. | Visual-diff workflows can identify changed screens, but a human still decides whether a claim is accurate. |
| SDK privacy scanning | Developers inspect source, manifests, and archived binaries. | Dependency scanners can enumerate protected APIs; the team must still map each API to a truthful purpose string. |
| Purpose-string drafting | Feature owners write and review concise, specific copy. | A service may generate drafts, but developers must verify that each sentence matches actual data use. |
| Credentials and review notes | The release manager assembles accounts, test devices, regions, and navigation steps. | A preparation service can package the material, but it cannot create valid access to a broken backend or bypass Apple’s requirements. |
Automation reduces omissions; it does not transfer responsibility for accuracy. Apple evaluates the submitted app, metadata, and explanations together, so a human familiar with the feature must approve the final assets and strings.
A release-gate checklist
Assets
- At least one screenshot exists for every required platform and device class.
- No class exceeds 10 screenshots.
- Every file is JPEG, JPG, or PNG with no alpha channel or transparency.
- Pixel dimensions and orientation match Apple’s current table.
- The device selected in App Store Connect matches the device shown.
- The first one to three images communicate the main use case.
- All screens, copy, plans, and capabilities match the submitted build and current description.
Privacy
- Protected-resource APIs are inventoried in application code and third-party SDKs.
- Each API has the exact required purpose key in the shipping target.
- Purpose strings state the concrete action and benefit in active, sentence-case language and end with a period.
- Permission requests occur when the feature needs access.
- Declining access leaves a usable fallback or a clear Settings path.
- No pre-permission screen imitates or pressures the system alert.
Review access
- Demo credentials and any two-factor or role instructions work on a clean install.
- Review notes explain the path to every gated feature.
- Tested devices and OS versions, external services, regional behavior, and changed functionality are documented.
- Required authorization or regulated-feature documents are attached.
Why these checks matter
Screenshot metadata is the customer’s first representation of the app, while a purpose string is the user’s explanation for surrendering access to sensitive data. Apple’s review guidance therefore treats both as product behavior, not decoration. A file that technically uploads but depicts an unavailable feature misleads customers; a permission alert that says only “for a better experience” withholds the information needed for an informed choice. Matching the asset, binary, and explanation removes the most common reasons for rejection and gives reviewers a reproducible path through the app.
Quick Recap
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.
