How to Submit App to App Store: 2026 Guide
Our 2026 guide shows you how to submit app to app store. Master prerequisites, build signing, ASO, & avoid common rejections with our step-by-step process.
You've finished the feature work, the crashes look under control, and the app finally feels ready. Then you open App Store Connect and realize the hard part wasn't only shipping the code. It's getting the release package, metadata, privacy disclosures, reviewer access, and account setup all aligned at the same time.
That's the point where many development teams start searching for how to submit an app to App Store and discover that the answer isn't a single upload button. It's a release process with technical, operational, and compliance checkpoints. If you miss one, Apple usually doesn't care that the app “works on your phone.”
The good news is that the maze is predictable once you know what Apple is evaluating. Reviewers need a testable build, a truthful store listing, complete privacy answers, and enough context to verify what your app does. If you're using React Native or Expo, there's another layer: identifier consistency, signing, and store account wiring have to match exactly.
Table of Contents
- The Final Boss of App Development
- Gathering Your Submission Prerequisites
- Building and Signing Your Production-Ready App
- Crafting Your Store Listing for Discovery and Approval
- Navigating App Store Connect to Final Submission
- Your Pre-Submission Checklist and Next Steps
The Final Boss of App Development
A finished app and a shippable app aren't the same thing.
Teams usually hit this wall the same way. The build runs. QA signs off. The feature list is locked. Then someone asks for the App Store screenshots, privacy policy URL, reviewer login, export compliance answers, and the exact versioned build that matches the listing. Suddenly release week turns into admin work, screenshots, form fields, and back-and-forth with Apple.
That mismatch catches even experienced developers because Apple doesn't review only code. Apple reviews the whole release package. The submission path is typically organized into five main steps, from creating the App Store Connect record and configuring Xcode through uploading the build, completing metadata and review information, and submitting for review, as described in this overview of the iOS upload workflow. That's why the final stretch feels bigger than expected. You're not uploading a file. You're proving that the app is technically valid, accurately described, and reviewable.
Practical rule: Treat submission as a release pipeline, not a handoff task. The binary, listing, privacy answers, and reviewer instructions should move together.
I've seen solid apps delayed for reasons that had nothing to do with the core product. A missing demo account. Screenshots showing flows that had changed. Permission text that didn't explain why the app wanted camera access. Metadata that promised a feature hidden behind a flag. None of those are exotic mistakes. They're normal release mistakes when the team treats the store as a final checkbox instead of part of delivery.
The fastest submissions usually come from teams that understand Apple's motivation. Apple wants reviewers to reproduce the app's intended experience quickly, compare that experience against the listing, and confirm that user data handling is disclosed clearly. Once you accept that logic, the process stops feeling arbitrary.
Gathering Your Submission Prerequisites
Release delays often start before the build exists. A team gets to submission week, then discovers the Apple account owner has left, the bundle ID does not match the provisioning setup, or the reviewer cannot get past the login screen. Those are process failures, not coding failures, and Apple treats them as reasons to stop review.
What has to exist before submission day
The goal at this stage is simple. Remove anything that can block review before Apple even evaluates product quality.
Here's the minimum set I want locked down early:
- Effective developer access: Confirm the correct people have the right roles in both the Apple Developer account and App Store Connect. If only one founder or contractor can create certificates, edit app records, or accept agreements, the release is fragile.
- A stable bundle identifier: Choose it once and keep it consistent across Xcode, App Store Connect, push configuration, sign-in providers, and any backend allowlists. Late changes create avoidable signing issues and service mismatches.
- App icon and brand assets: The icon is part of the binary and part of the listing. If design changes it late, the app package and the store assets both need to stay aligned.
- Privacy policy and support pages: Apple expects a working privacy policy URL and support contact, and the policy needs to match what the app does. If you collect account data, location, usage analytics, or identifiers, Apple compares your disclosures against your App Privacy answers and your in-app behavior, as outlined in Apple's App Store Review Guidelines.
- Review access materials: If the app needs login credentials, a specific user role, connected hardware, region-specific data, or a feature flag, prepare that information before the build reaches review.
The legal and operational side causes more rejections than many product teams expect, especially under Apple's privacy and data handling rules. Apps that request camera, microphone, location, notifications, or account access need permission text, metadata, and reviewer instructions that all describe the same purpose. If those pieces conflict, reviewers assume the implementation is incomplete or misleading.
Reviewers test the path you provide. If that path is blocked, unclear, or inconsistent with the listing, the app is likely to be rejected as not fully reviewable.
The cross-platform reality check
Cross-platform teams hit a specific class of release bugs. The React Native or Expo app may be functionally ready, but the store-facing configuration drifts from the native identifiers and service settings.
Common examples:
- The iOS bundle identifier differs from the value used for push notifications or OAuth redirect configuration.
- The app name, subtitle, screenshots, and in-app onboarding still reflect an old feature set.
- Expo configuration is updated, but the App Store Connect record or Apple capability setup is still based on an earlier build.
- Sign in with Apple is required because another social login is present, but the team only notices that at submission time.
Experienced mobile teams save time by treating store prerequisites as release dependencies with owners and due dates. Bundle IDs, privacy copy, reviewer accounts, export compliance answers, support URLs, and screenshots get reviewed during feature freeze, not after the binary is uploaded.
One more edge case is worth planning for early. If the app is not meant for public search results, Apple supports unlisted app distribution for specific business, partner, education, or internal-style use cases. That path still goes through App Review, but distribution works differently from a normal public listing, as Apple explains in its unlisted app distribution guidance.
If you are also shipping on Android, account setup can slow you down for different reasons. For new Play Console accounts, Google requires a 14-day closed test with at least 12 testers across multiple Android devices before release eligibility, according to Google's closed testing requirement for new personal developer accounts. Apple usually blocks launches on reviewability and disclosure. Google can block them on account maturity and test-process requirements.
A simple comparison helps:
| Platform | Common release blocker | Why it hurts |
|---|---|---|
| Apple App Store | Missing metadata, privacy disclosure, or reviewer access | Review stalls because Apple cannot verify the app experience and disclosures |
| Google Play | Closed testing requirement for new accounts | Public release is unavailable until the testing window is completed |
| React Native / Expo | Identifier, capability, and console config mismatch | The app runs, but store setup, services, and native settings do not line up |
Building and Signing Your Production-Ready App
Release week is where a lot of solid apps get exposed. The app runs fine in development, QA signed off, and then the production archive fails, the wrong bundle ID shows up in App Store Connect, or the submitted build points at staging. Apple treats those as trust problems, not small release hiccups.
What Signing Proves
Code signing confirms two things. The build came from a developer account Apple recognizes, and the app bundle was not modified after signing. If that chain breaks, distribution stops.
That is why signing problems rarely stay isolated. A signing error usually points to a mismatch somewhere else: the bundle identifier, enabled capabilities, provisioning profile, certificate ownership, or release target settings. Treat signing as a final verification of your release configuration, not as a box to tick at the end.
In a native iOS workflow, the path is straightforward: lock the production version, verify the release target and signing team, archive in Xcode, then upload through Organizer. Apple documents the build upload and processing steps in its Xcode upload guide for App Store Connect.
A short internal release checklist prevents a lot of last-minute churn:
- Freeze the version and build number before the archive is created.
- Confirm the bundle identifier matches the App Store Connect record.
- Check the signing team, certificate, and provisioning setup on the release target.
- Archive the same configuration you tested for release.
- Upload the exact archive you validated, not a later rebuild.
Here's a visual summary of that workflow before moving into tool-specific advice.
The React Native and Expo failure points
React Native and Expo reduce native setup work, but they do not reduce Apple's compliance requirements. That trade-off catches teams late. The JavaScript layer feels portable. Release identity, entitlements, and signing are still platform-specific.
For React Native and Expo projects, the common breakpoints are identifier drift and credential drift. Expo's guide to submitting to app stores calls out the need for a valid iOS bundle identifier, the right Apple account access, and correct submission setup. In practice, problems usually show up in one of four ways:
app.jsonor app config uses an identifier that does not match the store record- The Apple account in local or CI tooling is not the team that owns the app
- Capabilities were added in Apple Developer, but the build config was never updated to match
- Ownership, signing, or release responsibility changed mid-project without cleaning up credentials
Expo Application Services helps with certificate handling and build automation. It does not protect you from a bad app identity or a mismatched App Store Connect setup. If you plan to run eas submit --platform ios, make sure the production build, bundle ID, Apple team, and app record already line up.
For React Native teams, this is the key mindset shift. Shipping is not just generating an IPA. Shipping means the binary, signing setup, and runtime behavior all match the app record Apple will review.
What a clean production build looks like
A production build should be boring. It should open cleanly, use production services, show final branding, and expose only the features you are prepared to support and disclose.
I use a quick release table before any upload:
| Check | What to confirm |
|---|---|
| Identity | App name, bundle ID, package identifiers, version, and build number align |
| Environment | Production API endpoints, analytics keys, and feature flags are correct |
| Permissions | Camera, location, microphone, photos, and notification prompts match real app behavior |
| Capabilities | Push, Sign in with Apple, associated domains, IAP, and other entitlements are enabled consistently |
| Visual polish | App icon, launch behavior, and branded surfaces match what users and reviewers will see |
| Release behavior | No debug menu, mock login, test banner, placeholder copy, or staging data is exposed |
This is also where strategic review risk starts to show up. A build can compile, sign, and upload successfully, then fail review because permission prompts are vague, demo content looks unfinished, or reviewers hit a login wall with no access instructions. Cross-platform teams often treat those as metadata issues later in the process. In practice, they are build quality issues tied directly to compliance.
Crafting Your Store Listing for Discovery and Approval
You upload a clean build, hit submit, and still get rejected because the screenshots show a flow that no longer exists or the description promises a feature the reviewer cannot reach. That happens more often than build failures, especially on teams where engineering, product, and marketing finalize the listing at different times.
Metadata is part marketing and part compliance
Your App Store listing does two jobs. It has to help the right users find the app, and it has to match what Apple can verify in the build. If those two drift apart, review risk goes up fast.
Apple reviewers read the listing like a test plan. The app name, subtitle, description, screenshots, privacy details, and review notes all create expectations about what the app does, who it is for, and what access it needs. If the text says users can sign up inside the app but the build only supports invite-only login, expect questions. If screenshots show a polished dashboard but the review account lands on an empty state with no sample data, expect friction.
React Native and Expo teams get caught here in a predictable way. The JavaScript bundle changes quickly, but the store assets often lag behind because they sit in a separate workflow. A one-line copy change in the product can invalidate three screenshots and part of the description.
What reviewers compare against your app
Reviewers are checking for consistency, not clever positioning. Clear, narrow claims beat ambitious copy.
Use this order of priority:
- App name and subtitle: Make them recognizable and relevant to the product. Keyword stuffing makes the listing look spammy and can create review scrutiny.
- Description: Write from the released feature set. Leave roadmap items, beta language, and planned integrations out of the public copy.
- Screenshots and previews: Capture current UI from the release candidate, not Figma, not an old TestFlight build.
- Privacy details: Make sure the listing, privacy policy, and in-app behavior line up.
- Permission context: If the app asks for camera, microphone, location, photos, or notifications, the reason should be obvious from both the metadata and the in-app flow.
Founders usually want broader claims. Apple rewards precise ones.
I usually tell teams to treat every metadata field as a promise. If the build cannot support that promise during review, cut the claim or fix the app.
How to prepare assets without creating review risk
Screenshots are where rushed releases often break down. Every image is evidence of a feature, a screen, or a user path Apple may expect to find.
A safer workflow looks like this:
- Freeze the release UI before generating assets. If labels, tabs, or onboarding steps are still changing, wait.
- Capture from the production candidate. Use the same build you plan to submit, with production branding and realistic data.
- Keep captions literal. Say what the screen does now. Avoid aspirational marketing language.
- Test every public URL. Privacy policy, support page, and account deletion instructions should all load and match the app's behavior.
- Review the full listing as one package. The icon, subtitle, screenshots, and description should describe the same product for the same audience.
Cross-platform teams should add one more step. Recheck platform-specific behavior before exporting screenshots. I have seen Expo apps pass internal QA, then confuse review because iOS permission prompts, account screens, or purchase language differed from Android marketing assets the team reused.
For privacy-sensitive, regulated, or business apps, review notes matter as much as public metadata. If the app needs a demo account, special hardware, region-specific access, or a non-obvious user path, explain it clearly. Apple's App Review information guidance is the reference I use here because it maps directly to the access problems that delay otherwise solid submissions.
The trade-off is simple. Aggressive copy may help conversion at a glance, but inaccurate copy slows approval and can trigger rejection. On the App Store, approval comes first. Discovery improves when the listing is specific, current, and easy for both users and reviewers to verify.
Navigating App Store Connect to Final Submission
A lot of teams reach App Store Connect thinking the hard part is over. Then the release stalls because the wrong build gets attached, a compliance answer contradicts the app, or the reviewer hits a login wall and stops there.
At this stage, App Store Connect is less about data entry and more about risk control. The job is to make sure Apple sees one consistent package: the binary, the metadata, the privacy answers, the territories, and the reviewer instructions all need to describe the same product.
The submission flow that actually matters
The screen-by-screen flow is straightforward. The mistakes are not. In practice, the final submission pass usually comes down to five checks:
| Step | What you're doing | What can go wrong |
|---|---|---|
| Create app record | Match the app entry to the correct bundle ID and platform setup | Bundle ID mismatch, wrong app name, wrong SKU choice |
| Select uploaded build | Attach the exact production build intended for release | Selecting an older archive or a build with the wrong environment config |
| Set pricing and availability | Choose territories, release timing, and distribution settings | Shipping to the wrong regions or releasing before support is ready |
| Complete metadata and compliance | Confirm age rating, export compliance, privacy details, and content disclosures | Answers conflict with actual app behavior, which often triggers review questions |
| Submit for review | Send the full package with reviewer access and notes | Reviewer cannot log in, cannot reach key flows, or cannot verify a claimed feature |
Approval also does not guarantee the app appears instantly. Build your launch plan with a buffer. Apple can approve a version before it is visible in every storefront, and manual release gives you more control if timing matters.
React Native and Expo teams should slow down on the build-selection step. I have seen perfectly good submissions fail because the uploaded binary was built from the wrong EAS profile, pointed at staging services, or lacked a native permission string that never showed up in JavaScript testing. App Store Connect will happily let you attach the wrong build if the versioning looks plausible.
App Review Information is a common point of failure
The App Review Information section is a common point of failure. Incomplete notes can lead to an immediate rejection under Guideline 2.1 because the reviewer could not fully test the app or verify what the listing claims.
Apple's guidance on providing App Review information is the right reference here, and it matches what review teams ask for.
Include details that remove guesswork:
- Working credentials: Username, password, test account role, and any instructions for bypassing MFA or one-time-code flows during review
- Exact entry path: The taps needed to reach features that are not obvious from the home screen
- Required state or setup: Seeded data, backend flags, subscription status, device permissions, or account entitlements needed to see the feature
- Hardware or service dependencies: External accessories, location conditions, BLE devices, or third-party integrations required for the app to function as submitted
- Reviewer-safe route: The specific flow you want reviewed if the app has multiple branches, optional onboarding, or region-specific paths
Good review notes are concrete. “Use demo_user_apple_review, open Projects, tap Sample Site, then Start Scan” works. “Log in and explore the dashboard” wastes the reviewer's time and usually comes back as a question or rejection.
If your app serves a narrow audience, explain that too. Business tools, partner apps, and client-specific utilities often look sparse or confusing without context. Apple offers unlisted app distribution for apps that should be distributed through the App Store without public search visibility. That path still goes through review. It changes discoverability, not the approval standard.
Decisions here have product consequences
Release settings are not clerical details. They affect support load, compliance exposure, and how quickly you can recover from mistakes.
Automatic release is fine for low-risk updates with stable infrastructure. Manual release is safer if you need to coordinate a backend switch, regional rollout, press timing, or customer support coverage. For regulated apps or apps with account provisioning delays, I usually prefer manual release because it gives the team one last checkpoint after approval.
When Apple sends a review message, respond like an engineer debugging production. Reproduce the issue. Answer the exact question. If the reviewer is blocked, provide updated credentials or a revised build instead of arguing about intent. Fast, specific replies shorten the loop. Vague replies reset it.
Your Pre-Submission Checklist and Next Steps
The last hour before submission should be boring. If it feels chaotic, the package isn't ready yet.
The last pass before you click submit
Use a final pass that focuses on consistency, not optimism.
- Build and listing match: The version, app name, icon, and key flows in the binary match the listing you prepared.
- Reviewer access works: Login credentials are valid, account state is seeded correctly, and any gated features are reachable.
- Permissions are justified: If the app asks for sensitive permissions, the app and metadata explain why.
- Privacy details are complete: Policy URL, data-use disclosures, and related answers align with actual app behavior.
- Release settings are intentional: Pricing, availability, and release timing are set the way you mean them to be.
A useful gut check is simple: if a reviewer opened the app cold and followed only your notes, would they see exactly what your listing promises? If the answer is “mostly,” don't submit yet.
What to do after review starts
Once the app is in review, monitor messages closely and keep the release owner available. Fast, specific responses help. Slow, vague responses stretch the process.
If Apple asks a question, respond with one of these:
- A precise reproduction path
- Updated credentials
- Clarification about intended behavior
- A new build that fixes the issue cleanly
Teams often don't need more tutorials on how to submit app to app store. They need a disciplined release process that treats submission as part of the product, not paperwork after the product.
If you'd rather stay focused on building than wrestling with store packaging, reviewer notes, screenshots, privacy documents, and React Native or Expo signing setup, LetsDeployIt handles the full submission process for Apple App Store and Google Play. They prepare the store assets, wire up EAS Build and Submit, manage reviewer communication, handle resubmissions, and even run the required Google Play closed test for new accounts.