How to Submit App to Apple Store: 2026 Guide
Submit app to apple store - Learn how to submit your app to the Apple Store with our step-by-step guide. Get your app approved faster and reach millions of
Apple reviewed 9,100,620 app submissions and rejected 2,093,244 in its 2025 App Store Transparency Report, which is a blunt reminder that to submit App to Apple Store is to enter a serious review system, not a file upload screen. At that scale, approval depends on more than a clean build. It depends on whether Apple can verify the app, understand the metadata, and reproduce the experience without guesswork.
For teams shipping React Native and Expo apps, the surprise usually isn't the binary. It's the paperwork around it, the reviewer access package, and the privacy disclosures that drift out of sync with the app itself. Those are the gates that slow down otherwise solid launches.
Table of Contents
- What Submitting to the Apple App Store Involves
- Enrolling in the Apple Developer Program and Setting Up Signing
- Building and Signing Your App for Distribution
- Preparing App Store Connect Metadata
- Giving Apple Reviewers Access to Your App
- TestFlight, Final Submission, and Responding to Rejections
- Timeline, Final Pre-Submit Checklist, and When to Outsource Submission
What Submitting to the Apple App Store Involves
Apple's submission flow is a chain of gates, and each gate checks a different thing. The account has to exist, the app has to be signed correctly, the binary has to validate, the metadata has to match reality, and the reviewer has to be able to use the product. Apple's publishing documentation also says that after approval, release can still take up to 24 hours to go live, with manual, automatic, or phased release options available in App Store Connect (Apple publishing overview).
The point of that pipeline is control. Apple's 2025 transparency report shows 9,100,620 submissions and 2,093,244 rejections, which is roughly 23% rejected, so a bad upload isn't just a delay. It usually means the process resets while someone on your team fixes something that should have been caught earlier (Apple transparency report).
The standard sequence
A clean launch usually starts with developer account setup, then moves into build signing, archive validation, App Store Connect metadata, review access, and only then final submission. The order matters because Apple will block you on a missing agreement, a mismatched bundle ID, or a privacy answer that does not match the app you built.
A useful mental model is to treat the process as a compliance chain, not a deployment button. The binary is only one link. Metadata, reviewer notes, and disclosure consistency are the other links, and that is where many first submissions get slowed down.
Login-walled apps add a second gate that guides often skip. If the reviewer cannot get into the app without a working demo account, clear test instructions, and any needed role-specific access, the binary can be fine and the review can still stall. I have seen more delays from bad reviewer-access packages than from compile errors, because the fix is usually in App Store Connect notes, not in Xcode.
Privacy-manifest and SKU-disclosure drift creates a different kind of rejection. The app store record says one thing, the binary or its linked SDKs do another, and the reviewer is left with a mismatch between permissions, data use, or in-app behavior. That mismatch is easy to miss when a React Native app pulls in third-party modules that changed after the last release, so I always check the metadata screens and the privacy answers against the actual shipped build before submission.
Practical rule: If Apple cannot understand your app from the store record and the reviewer account you provide, it will review your team, not your product.
Enrolling in the Apple Developer Program and Setting Up Signing
Everything starts with the account layer. You need an Apple ID, enrollment in the Apple Developer Program, and the right account type for the team that will own the app. A personal account can work for experiments, but it becomes a headache fast if the product later needs an organization account, shared access, or more formal distribution controls.
Signing is where many teams burn time for no good reason. Apple separates development signing from distribution signing, and the distribution side is what matters for App Store release. The practical default in Xcode is still automatic signing, because it reduces certificate and profile churn and can handle much of the identity work for you when the project is set up correctly (Apple developer submission guide).
What to set up before you build
The clean path is straightforward. Create or confirm the Apple ID, enroll in the developer program, make sure the team has the correct account ownership, and then create the App Store distribution certificate and provisioning profile needed for release builds. If the app is tied to devices for testing, register the relevant UDIDs during development, but don't confuse that with distribution readiness.
A lot of submission delays come from boring admin mistakes, not code. The two that show up most often are enrolling with the wrong Apple ID for the team structure, and forgetting to accept the latest license agreement before upload. Both produce avoidable friction because the build can look ready while Apple's portal is waiting on account housekeeping.
What a release-safe setup looks like
Use Xcode's signing automation unless you have a reason not to. It keeps the distribution identity aligned with the bundle ID and reduces the odds that the archive you validated locally won't upload cleanly later. For teams shipping more than one app, keep the naming of certificates and profiles disciplined, because messy naming is how people end up uploading the wrong target on deadline day.
Keep the account owner and the build owner in the same Slack thread. If one person accepts the legal agreement and another person uploads the archive, somebody always assumes the other person checked it.
Building and Signing Your App for Distribution
In 2026, there are three real pipelines: native Xcode archive and upload, Transporter, and Expo EAS Build/Submit for React Native or Expo projects. The right one depends on how much signing pain you want to own. If the app is native iOS, Xcode is the default. If the team likes repeatable uploads or CI-driven distribution, Transporter is useful. If the app is React Native or Expo and the team wants Apple signing handled with less manual certificate work, EAS is usually the least annoying path.
Here's the practical split. Xcode is best when the iOS team already lives there and wants to inspect the archive before upload. Transporter fits teams that already have a signed build file and just want a clean upload path. EAS is the more comfortable choice for React Native and Expo projects because it wires signing into the build and submission flow instead of making your engineers babysit certificates.
The native Xcode path
In Xcode, archive the app for a generic iOS device, validate the archive, and then distribute it to App Store Connect. The archive step catches obvious build problems before Apple sees them, which is exactly where they belong. Validation is worth doing every time, because an archive that builds locally can still fail once export settings or signing details are checked more closely.
The React Native and Expo path
For React Native or Expo, EAS Build and eas submit simplify the certificate story. A typical profile keeps build behavior separate from release behavior, which is useful because you don't want ad hoc experiments touching your production signing path. A minimal profile often looks like this in practice:
eas.json profile example:
- build
- production: release-oriented settings
- submit
- production: App Store submission target
The exact keys vary by project, but the idea is always the same. Keep production settings isolated so test builds don't contaminate release signing. That discipline saves more time than any clever workaround ever will.
Build pipeline comparison
| Project Type | Recommended Pipeline | Manual Certificate Handling |
|---|---|---|
| Native iOS | Xcode archive and upload | Low, if automatic signing is enabled |
| React Native | EAS Build plus eas submit |
Low to moderate |
| Expo | EAS Build plus eas submit |
Low to moderate |
| CI-heavy team | Transporter or scripted upload | Moderate |
The wrong shortcut here is hand-managing certificates across multiple people and multiple branches. It works until the day one expired profile blocks the release train.
Preparing App Store Connect Metadata
App Store Connect is where otherwise decent submissions become review problems. The app record has to point at the right bundle ID, and the App Information screen has to match the product you're shipping. That means app name, subtitle, category, privacy policy URL, and the rest of the store-facing fields need to be aligned before you hand the build to Apple.
The store listing matters because review checks don't happen in isolation. Apple looks at screenshots, the description, app behavior, and the disclosures together. If the description promises a feature the reviewer can't find, or the screenshots show a state that doesn't exist in the build, that's an avoidable delay.
Metadata that trips teams up
The most common misses are not dramatic. They're the screenshot sizes, the privacy answers, and the little compliance fields people leave for later. Screenshots need to match the required device families you support, and the app preview or promotional assets need to be consistent with the current version of the app, not last sprint's demo.
The App Privacy section deserves the same care as the binary. Apple now expects privacy disclosures, privacy manifest work, and required reason API declarations to line up with what the app and its SDKs do. A separate submission guide also emphasizes checking first-party code and every SDK before answering privacy questions, because the review surface has expanded beyond the app bundle itself (App Launch Flow submission checklist).
Fields worth double-checking
- Copyright: Make sure the legal line is present and current.
- Age rating: Answer the questionnaire truthfully, because hidden content and permissions matter.
- Export compliance: Don't leave it for the last minute.
- Content rights: Confirm you have the rights to the material in the app.
- Advertising Identifier: Answer it carefully if the app uses ad-related tooling.
Keywords deserve restraint. Use the field strategically, but don't stuff it with a pile of unrelated terms just to chase search traffic. Apple's reviewer sees the same metadata your users do, and sloppy keyword practices make a listing look rushed.
The strongest store records are boring in the best way. They're consistent, specific, and easy to verify against the build.
Giving Apple Reviewers Access to Your App
A lot of apps do not stall because the code is broken. They stall because the reviewer can't get past the login screen, the role gate, or the hidden first-use flow. Apple explicitly asks developers to provide access and explain unique behavior so the team can complete review, which makes reviewer access part of launch readiness, not an afterthought (Apple Tech Talks on review access).
That matters most for apps with authentication, location dependence, camera workflows, or gated content. If the reviewer has to guess, your review is already slower than it needs to be.
What the access package should contain
At minimum, include working demo credentials, a short reviewer note, and a reproducible path to the core feature. If the app has sample data, seed it. If the app requires a specific role, provide one. If a normal user sees a blank state until onboarding is complete, add a clean fallback path so the reviewer doesn't have to invent one.
A good reviewer note reads like instructions, not marketing copy. It should tell Apple where to tap, what to expect, and what to do if a permission prompt appears. If the product has a hidden feature flag, mention it. If the app needs location, camera, or a subscription account, give the reviewer the exact path that provides the experience.
Examples that actually help
- Food-delivery apps: Pre-seed a few test restaurants and explain which one shows the order flow.
- Fitness apps: Create a demo user with some progress history so the dashboard doesn't open empty.
- B2B apps: Offer a sandbox mode behind a reviewer-only build flag so the review team can see the admin path without touching live data.
Reviewers don't need your production stack. They need one reliable path through the product.
The big mistake is assuming a polished login screen is enough. It isn't. If Apple can't reproduce the core journey quickly, the app sits in Waiting for Review while your team answers avoidable questions.
TestFlight, Final Submission, and Responding to Rejections
TestFlight is the safest place to catch review-adjacent problems before they reach production. Internal testing can involve up to 100 team members, and external testing needs a brief Apple review before you can invite testers publicly. That makes TestFlight useful for one thing in particular, proving that the build, onboarding, permissions, and flows all work outside your dev machine (Apple developer submission guide).
Before you promote a build, check the app the way a reviewer will. Open the app fresh, sign in with the reviewer credentials, verify every call to action on the store listing, and test the flows that depend on location, camera, or account state. If a screen only works after three hidden steps, document them in the reviewer notes.
What the statuses mean
Waiting for Review usually means the build has been submitted and is queued. In Review means Apple is actively looking at it. Ready for Sale means approval is done and the release path is set, though the app can still take time to appear publicly after approval, as noted in Apple's publishing flow (Apple publishing overview).
The rejection playbook is simple, but teams still get it wrong. Read the Resolution Center message carefully, fix the exact issue Apple cited, and respond with the change set plus proof if needed. Don't rewrite the whole app because one screen broke a rule.
Common rejection categories and the direct fix
- Guideline 2.1, crashes or bugs: Reproduce the bug, fix the failure path, and retest on a clean install.
- Guideline 2.3, accurate metadata: Make the screenshots, description, and actual app behavior line up.
- Guideline 4.0, design: Simplify confusing navigation or broken flows.
- Guideline 5.1.1, privacy: Align the privacy policy, manifest, and in-app behavior.
- Guideline 4.2, minimum functionality: Add enough real utility so the app isn't just a shell.
The fastest teams treat rejections like bug reports, not verdicts. Apple tells you what failed. Your job is to fix exactly that, then prove it cleanly.
Timeline, Final Pre-Submit Checklist, and When to Outsource Submission
A clean React Native or Expo launch can still be done in 10 to 14 days if the app, metadata, reviewer access, and privacy details are prepared before the build reaches App Store Connect. 30+ days is still common when the account is new, the listing is rushed, or one rejection starts a rebuild-and-resubmit loop. In practice, the delay usually comes from release operations, not from Apple doing something unpredictable.
The last review pass should be short and unforgiving. Check the signed archive, confirm the bundle ID, verify the screenshots, review the App Privacy answers, and read the reviewer notes as if you had never seen the app before. If the store record promises a feature, the feature needs to exist, and it needs to be easy to find on first launch.
Login-walled apps need a separate check here. Apple reviewers should not be blocked by a normal production flow that expects a customer account, a one-time code tied to a personal phone, or a staff-only permission set. Reviewer-access packages, test credentials, and fallback steps should be ready before submission, because that is one of the fastest ways to avoid a clean binary getting stalled by a preventable access issue.
Privacy-manifest and SKU-disclosure drift causes another class of rejection that teams miss until the end. The app can be technically fine while the metadata says one thing, the privacy answers say another, and the binary behaves differently again after a late SDK change. I look for that mismatch on every release, because Apple will compare what you shipped against what you disclosed.
Final pre-submit checklist
- Binary: Archive validated, correct build selected, and production signing confirmed.
- Metadata: App name, subtitle, description, keywords, and support URLs all match the current release.
- Screenshots: Required device sizes are present and current.
- Privacy: Manifest, privacy answers, and in-app behavior are consistent.
- Reviewer notes: Credentials, access steps, fallback states, and any reviewer-access package details are included.
This is also the point where outsourcing can make sense. LetsDeployIt is one option for React Native and Expo teams that want submission handled end to end, including store copy, ASO keywords, screenshots, icon polish, privacy policy and Terms hosting, reviewer notes, and resubmissions, with pricing starting at $999 for one store or $1,799 for both Apple and Google Play. It also offers a 100% approved-or-money-back guarantee, and its published scope excludes developer account fees and ongoing infrastructure costs.
That kind of service helps when the release path needs to be run as a project, not a side task. If you are preparing a React Native or Expo launch and want fewer surprises in App Store Connect, visit LetsDeployIt's submission management service and compare its submission management to the way your team is handling review access, privacy cleanup, and final store assets today.