Guide · 8 min read
App Store Connect for First-Time Submitters: What to Fill In and In What Order (2026)
App Store Connect is Apple's back-office for every app on iOS — but it's simultaneously a metadata system, an ASO platform, a privacy compliance interface, and a legal declaration tool. First-time submitters nearly always navigate it out of sequence: uploading a binary before finishing metadata, or filling in fields without knowing which ones Apple's algorithm actually indexes. Since April 2026, the iOS 26 SDK is required for all new submissions. Here is the exact sequence to work through App Store Connect, and why the order matters more than most guides admit.
The order trap — why filling App Store Connect backwards costs you a week
The instinct for most first-time submitters is to upload the binary first. The app is built, Xcode archived it, so uploading feels like the starting line. This reverses the correct sequence. App Store Connect's fields interact with each other in ways that punish out-of-order completion: uploading a binary before metadata is finalized puts a review clock on fields that aren't ready. The fields requiring the most strategic thought — your app name, subtitle, keyword field, and screenshots — get rushed because a binary is already in the queue.
The correct sequence: create your app record (bundle ID, SKU, pricing tier) → finalize ASO metadata → prepare and upload screenshots → do a TestFlight build → then submit to App Review. Your bundle ID, once associated with an app record and submitted to the store, cannot be changed. Getting it wrong requires creating an entirely new app record, losing any review history, rating count, or search rank signals already accumulated. No other first-time mistake in App Store Connect is as permanent.
One practical advantage of working through fields in the correct order: App Store Connect runs a completeness validation when you click Submit for Review, blocking submission if required fields are missing. Developers who upload binaries first and fill metadata second hit these blocks with a binary already in queue — a worse position than catching them early. Working in sequence surfaces errors before any review clock starts.
Create your app record before your first binary — bundle ID, SKU, and pricing tier
Your first action in App Store Connect is creating the app record before uploading anything. Navigate to Apps → + → New App and specify: platform (iOS, macOS, tvOS — all addable later), app name (up to 30 characters, also your primary ASO field), bundle ID (must match your Xcode project identifier exactly), and a SKU (any alphanumeric string, internal and never visible to users or search). Both the app name and bundle ID must exist in your Apple Developer account before this form can complete.
The bundle ID requires separate setup in the Apple Developer portal under Certificates, Identifiers & Profiles — it's not created inside App Store Connect. If your app uses push notifications, in-app purchases, HealthKit, Sign in with Apple, or any entitlement-requiring capability, the bundle ID must have those capabilities added in the developer portal before submission. Missing this step produces a build configuration error that Xcode often surfaces only at archive time. Create the identifier in the portal first, add capabilities, download the provisioning profile, then open App Store Connect's new app form.
Pricing and availability should be configured before you move to metadata. Apple's tier system sets your price in your base currency and calculates equivalent prices across all storefronts automatically. One 2026 item worth acting on immediately: Apple's Small Business Program reduces the App Store commission from 30% to 15% for developers earning under $1 million in annual App Store proceeds. The application is in App Store Connect's Business section. Apply before your first paid app goes live so initial revenue is invoiced at the lower rate from the first transaction.
Metadata first: app name, subtitle, and keyword field are ASO infrastructure — not admin forms
Three fields in App Store Connect determine whether your app surfaces in search — and all three are treated as admin forms by most first-time submitters. Your app name (30 characters), subtitle (30 characters), and keyword field (100 characters) are the primary surfaces Apple's search algorithm indexes. Every character should be chosen for search intent. The app name is your highest-weighted keyword slot. Front-loading your primary search term matters: 'Habit Tracker — Daily Goals' and 'Daily Goals — Habit Tracker' index differently in App Store search despite containing identical words.
The subtitle is routinely wasted on taglines. 'Your life, organized' carries zero search value. 'Daily planner and reminder' is a phrase users actually type. Use the subtitle for the secondary keyword that didn't fit naturally in your app name. The keyword field is 100 characters of comma-separated terms not already in your title or subtitle — write them without spaces after commas to fit more. Repeating words from your title wastes characters without compounding rank. See the free keyword research guide for the method to identify which specific terms to target before finalizing these fields.
One 2026 addition to App Store Connect's metadata layer: Accessibility Nutrition Labels, now in the App Information section. These let you declare which accessibility features your app supports — VoiceOver, Voice Control, Larger Text, Sufficient Contrast, Reduced Motion. Completing this isn't currently mandatory, but it appears alongside your privacy nutrition label on the product page, visible to users evaluating the app before they download. First-time submitters who complete it signal product quality at a level that costs five minutes in App Store Connect and requires no code changes.
Privacy Manifest and Nutrition Label — the two 2026 fields that block most first submissions
Apple's Privacy Manifest requirement is one of the most common rejection causes for first submissions in 2026. A Privacy Manifest is an XML file — PrivacyInfo.xcprivacy — added to your app bundle that declares which privacy-sensitive APIs your app accesses, the purpose for each access, and whether data is linked to user identity. If your app uses any required reason API category (File Timestamp, System Boot Time, Disk Space, Active Keyboard, or User Defaults APIs) without declaring the purpose, your submission fails under Guideline 5.1.2. Xcode 15 and later include a PrivacyInfo.xcprivacy template — add it to your app target before archiving.
Third-party SDKs are where most Privacy Manifest rejections come from unexpectedly. Apple maintains a list of SDKs that must include their own Privacy Manifests — Firebase, Amplitude, Adjust, and RevenueCat are all on it. Even if your own code has no protected API usage, a linked SDK that calls those APIs without a manifest carries the violation into your submission. The fix: check every third-party SDK against Apple's required SDK list, update each to its latest version, and use Xcode's Generate Privacy Report to verify all manifests are present in your final archive.
The App Store privacy nutrition label — the consumer-facing summary on your product page — is a separate declaration from the Privacy Manifest. It requires you to declare data types your app collects, their purpose, and whether each is linked to user identity or used for tracking. Inaccurate declarations are a rejection reason. Selecting 'We do not collect data' when your app links any analytics SDK that collects session data will be caught in App Review. Complete the nutrition label after your Privacy Manifest is finalized — both documents cover the same API surface from different angles, and reviewing one before the other catches inconsistencies.
Screenshots and preview video — upload assets before the binary enters review
Screenshots and preview videos can be uploaded to App Store Connect before a binary is submitted — and they should be. Having your full screenshot set ready before submission means App Review evaluates your listing as a complete package. The required iPhone screenshot size in 2026 is 1320×2868px (6.9-inch). Uploading at this size covers all smaller iPhone display families automatically. For iPad, the required size is 2064×2752px (13-inch). The complete table of every required dimension is in the screenshot sizes reference.
One consideration specific to first-time submitters in 2026: iOS 26's Liquid Glass interface is now standard across current devices, and screenshots taken on iOS 15–17 look visually dated on current App Store product pages. This isn't a rejection reason — App Review doesn't enforce screenshot currency — but it consistently lowers conversion against competitors whose screenshots reflect the current iOS aesthetic. Record and export from a Simulator or device running iOS 26. Use the screenshot editor to build device-framed marketing screenshots at the exact required dimensions.
TestFlight first — route every new binary through beta before App Review sees it
TestFlight — Apple's first-party beta distribution system built into App Store Connect — accepts the same binary archive you submit to App Review. The standard first-timer workflow uploads directly to App Review. The better workflow routes every new binary through TestFlight first. TestFlight runs your binary through Apple's processing pipeline and distributes to up to 100 internal testers within minutes of processing completing — before any App Review clock starts. Issues visible here: code signing mismatches, missing entitlements, configuration differences between development and distribution certificates — all caught reversibly before they consume your App Review window.
External testing on TestFlight — up to 10,000 users via a public link — requires a brief TestFlight review, typically under 24 hours, but doesn't require your App Store listing metadata to be finalized. This means you can distribute a working beta and collect real feedback while the public listing is still being optimized. The binary that passes TestFlight external review is submittable directly to App Review with no re-archiving. First-time submitters who skip TestFlight regularly submit builds with distribution-environment issues that never appeared in development — TestFlight catches them before those issues delay launch.
After you submit — what the review queue looks like and how to respond when it's rejected
Apple reviews approximately 90% of submissions within 24 hours. Status is visible in real time in App Store Connect's Resolution Center: 'Waiting for Review' means queued; 'In Review' means a reviewer is actively evaluating; 'Metadata Rejected' means a listing field had an issue separate from the binary — fixable without resubmitting the binary; 'Rejected' means a guideline violation was found; 'Ready for Sale' means your app is live. Turn off email filtering for Apple's domain before submitting — rejection notices often land in promotional filters.
Rejections require a response through the Resolution Center, not by emailing Apple. Read the notice completely — Apple cites the specific guideline and describes what the reviewer encountered. Address the issue, write a brief note explaining what changed and why, then resubmit. Your resubmission enters the same queue as new submissions; there's no priority lane for second attempts. If the rejection appears incorrect, an App Review Board appeal — accessible from the Resolution Center — escalates to a separate team. For the most common rejection causes and their specific fixes, the App Store rejection guide covers each one.
Fill App Store Connect in the right order and most surprises disappear
App Store Connect's fields aren't uniform in strategic weight. Your bundle ID is immutable once set. Your keyword field is invisible to users but determines whether they find you in search. Your Privacy Manifest is invisible to everyone except Apple's review pipeline — and missing it blocks submission. Getting the sequence right means the difference between a smooth first launch and a rejection cycle that costs a week while competitors accumulate reviews.
The sequence: app record → pricing → metadata → privacy declarations → screenshots → TestFlight → App Review. Each step builds on the last. None of them require paid tools — only deliberate execution in order.
Build your App Store screenshots in the editor →
Frequently asked questions
What order should I fill in App Store Connect as a first-time submitter?
Create your app record first (bundle ID, SKU, pricing tier), then finalize ASO metadata (app name, subtitle, keyword field), then upload screenshots, then do a TestFlight build to catch distribution-environment issues, then submit to App Review. Completing metadata before uploading a binary lets you make ASO adjustments without a review clock running on an incomplete listing.
Can I change my bundle ID after submitting to the App Store?
No. Your bundle ID is permanent once your app record is submitted and associated with a build. Getting it wrong means creating a new app ID in the Apple Developer portal and a new App Store Connect record — losing any prior reviews, ratings, and search rank signals. Set it correctly in the developer portal before creating the App Store Connect record.
Does my app need a Privacy Manifest in 2026?
Yes, if your app — or any SDK it links — uses any of Apple's required reason API categories: File Timestamp, System Boot Time, Disk Space, Active Keyboard, or User Defaults APIs. The manifest is a PrivacyInfo.xcprivacy file added to your Xcode target. Missing it triggers rejection under Guideline 5.1.2. Check all third-party SDKs against Apple's required SDK list and update them to versions that include their own manifests.
How long does App Store Review take for a first submission in 2026?
Apple reviews approximately 90% of submissions within 24 hours and 98% within 48 hours. Completing all required fields before submitting — rather than filling placeholders and planning to update later — correlates with faster reviews because complete listings don't trigger back-and-forth over missing metadata.
Do I need to use TestFlight before submitting to the App Store?
It's not required, but routing your binary through TestFlight first is the right practice for first submissions. TestFlight runs the same processing pipeline as App Review — provisioning validation, entitlement checks — without starting a review clock. Issues that only surface under App Store distribution conditions appear here, where you can fix them before consuming the App Review window.