App Store Submission Checklist: Screenshots, Metadata & Assets

Before you open App Store Connect, make sure you have every required element ready. Gathering everything in advance prevents the common scenario where you rush through the submission form and realize midway that you are missing a critical asset.

Start with your Apple Developer account. Confirm your membership is active and your team roles are properly configured. The Account Holder or Admin role is required to submit apps. If you are part of a team, verify that someone with the right permissions will be available to complete the submission. Next, make sure your app's bundle ID is registered in the Developer portal and matches the bundle ID in your Xcode project. Mismatches here cause build upload failures that can be confusing to debug.

Prepare your app binary. Build your app with the Release configuration, not Debug. Archive it in Xcode and validate it before uploading. Common validation failures include missing required device capabilities, incorrect provisioning profiles, and missing privacy manifest declarations. Apple now requires a privacy manifest (PrivacyInfo.xcprivacy) for all new submissions, detailing which APIs your app uses and why. If your app includes any third-party SDKs, verify that each SDK provides its own privacy manifest or that you have documented their API usage in yours.

Create a testing account for App Review. If your app requires login, provide valid test credentials in the App Review notes field. This seems obvious, but expired test accounts are one of the top reasons for review delays. Create a dedicated review account that will not expire, and test the credentials yourself immediately before submission. Include step-by-step instructions for accessing any features that are not immediately obvious, especially features behind paywalls or onboarding flows.

Apple requires screenshots for specific device sizes and enforces exact pixel dimensions. Uploading screenshots at the wrong size results in an immediate rejection without review.

For iPhone, you need screenshots for at least two display sizes. The 6.7-inch display (iPhone 16 Pro Max, iPhone 15 Pro Max) requires 1320 x 2868 pixels in portrait or 2868 x 1320 in landscape. The 5.5-inch display (iPhone 8 Plus) requires 1242 x 2208 pixels portrait or 2208 x 1242 landscape. You can upload between 1 and 10 screenshots per device size, but providing at least 4-6 gives users a comprehensive view of your app. Apple uses the 6.7-inch screenshots as the default display for most devices, so prioritize the quality and messaging of this set.

For iPad apps, you need screenshots for the 12.9-inch iPad Pro at 2048 x 2732 pixels portrait or 2732 x 2048 landscape. The 11-inch iPad Pro screenshots should be 1668 x 2388 portrait or 2388 x 1668 landscape. iPad screenshots are displayed separately from iPhone screenshots in the store, so they should show the iPad version of your app, not just scaled-up iPhone screenshots.

All screenshots must be PNG or JPEG format with no transparency. Maximum file size is 10 MB per image. Screenshots cannot contain device status bars showing real carrier names, must not include content that violates Apple's guidelines, and should accurately represent the current version of your app. Apple specifically looks for screenshots that show features not present in the submitted binary, which is a common rejection reason during major redesigns when screenshots are prepared before the new build is finalized.

App Preview videos are optional but recommended. You can upload up to 3 preview videos per device size, each between 15 and 30 seconds long. Videos must be in M4V, MP4, or MOV format, and their dimensions must match the screenshot size for that device. The first frame of your video serves as the poster image when the video is not playing, so make sure it works as a standalone screenshot.

App Store Connect requires several text fields, each with strict character limits. Preparing this text in advance (in a document outside App Store Connect) lets you carefully craft each field without the pressure of the submission form.

Your app name can be up to 30 characters. This is the primary title displayed in search results and on your product page. Choose a name that is memorable, easy to spell, and includes your most important keyword if it fits naturally. Do not stuff keywords into the app name. Apple rejects apps with names like "Photo Editor: Best Camera Filter Selfie Beauty" because it violates their naming guidelines.

The subtitle is up to 30 characters and appears directly below your app name in search results. Use this space to communicate your primary value proposition or target audience. "Meditation for beginners" or "Track workouts and meals" are effective subtitles because they immediately tell users what the app does. The subtitle is indexed for search, so it is a valuable place for a secondary keyword.

Your description can be up to 4,000 characters. The first three lines (approximately 170 characters) are visible before the "more" button, so they carry the most weight. Write them as a compelling pitch. The rest of the description should provide detailed information about features, use cases, and any subscription or pricing details. Apple does not index the description for App Store search (unlike Google Play), so optimize it for conversion rather than keywords.

The keywords field accepts up to 100 characters, separated by commas with no spaces. This is your primary ASO lever. Use all 100 characters. Do not repeat words from your app name or subtitle, because Apple already indexes those. Do not use spaces after commas. Do not use plurals if you have the singular (Apple matches both). Research competitor keywords and long-tail phrases that have meaningful search volume but lower competition.

Additional required fields include the promotional text (up to 170 characters, can be changed without a new submission), the privacy policy URL (mandatory for all apps), your support URL, and age rating questionnaire responses. Missing any of these causes a submission failure.

Understanding the most frequent rejection reasons helps you proactively address issues before Apple's review team flags them. The most common rejections fall into a few predictable categories.

Guideline 2.1 (Performance: App Completeness) is the most frequent rejection. This covers apps that crash, have broken links, display placeholder content, or include features that do not work as described. Before submitting, test every feature in your app on a physical device running the latest iOS version. Test edge cases like no internet connection, empty states, and permission denials. If a feature is "coming soon," either remove it from the app or clearly mark it as upcoming without making it look broken.

Guideline 2.3 (Performance: Accurate Metadata) catches apps whose screenshots, descriptions, or previews do not accurately represent the app experience. If your screenshots show a feature that was removed in the latest update, Apple will reject the submission. If your description claims functionality that requires a subscription but does not disclose the pricing, that is also a metadata violation. Always regenerate your screenshots from the actual submitted build, and proofread your description against the current feature set.

Guideline 5.1.1 (Data Collection and Storage) has become increasingly strict. Your app must include a privacy policy, accurately declare all data collection in the App Store privacy nutrition labels, and present appropriate permission request dialogs. Apple now cross-references your privacy declarations with the APIs your app actually calls. If your app uses the location API but your privacy label says you do not collect location data, the discrepancy will trigger a rejection.

Guideline 4.0 (Design: Copycats) and Guideline 4.3 (Design: Spam) catch apps that closely resemble existing popular apps or that are essentially duplicate submissions with minor changes. If your app uses a UI pattern inspired by a well-known app, make sure your implementation adds meaningful original value. Apps that are simple wrappers around a website or that duplicate functionality available in other apps from the same developer are regularly rejected under these guidelines.

The best approach to avoiding rejections is to treat the App Store Review Guidelines as a pre-submission checklist. Read through the relevant sections before every major submission. Apple updates these guidelines regularly, and requirements that did not exist six months ago may be enforced today.