Apple reviewed 9,100,620 app submissions in 2025 and rejected 2,093,244 of them, with 387,087 later approved after rejection, according to Apple’s App Store transparency data. That works out to roughly 23% initially rejected, so iOS app submission isn’t a ceremonial upload step. It’s a high-scrutiny release process where signing, binary behavior, metadata, storefront policy, and reviewer access all need to hold together.
Apple also says 90% of submissions are reviewed in less than 24 hours on its App Review page. Fast review is useful, but it doesn’t make approval automatic. In practice, the teams that ship calmly treat submission as a rejection-resilience system: they make the native shell stable, prepare a reviewer-friendly build, stage changes carefully, and keep a safe path for fixing web-layer issues without turning every urgent copy or styling bug into a new store submission.
Table of Contents
- What iOS App Submission Really Involves
- Prerequisites That Prevent Signing Failures
- Building and Signing Your Capacitor App for Release
- Uploading Testing With TestFlight and Completing App Store Metadata
- Handling App Review and Avoiding Common Rejections
- Final Checks and Shipping Updates Without Resubmitting Everything
What iOS App Submission Really Involves
Consider a typical failure pattern: a team finishes a Capacitor app late on a Friday, archives it in Xcode, uploads the build, and assumes the hard part is over. During review, Apple finds that the login account fails, a backend endpoint is unavailable, or a feature described in the metadata cannot be reached. The rejection may arrive quickly, but the fix still requires a new build, another upload, another review cycle, and a release plan that never allowed for interruption.
Treat submission as a rejection-resilience system, not as an upload checklist. The complete path starts before Xcode:
- Enroll in the Apple Developer Program and confirm that the people handling signing and App Store Connect have the right access.
- Create and configure the app identity, including the Bundle ID, capabilities, certificates, and provisioning setup.
- Create the App Store Connect record with the matching bundle identifier.
- Build and sign the release archive in Xcode or through a controlled CI workflow.
- Upload the binary, then use TestFlight to exercise the exact artifact intended for distribution.
- Complete metadata and review information, submit the version, and respond to Apple’s decision.
Three layers Apple evaluates
The package has three connected layers.
The binary layer is the compiled application, its signing, entitlements, native plugins, privacy declarations, and runtime behavior. The metadata layer includes screenshots, description, keywords, URLs, age-rating responses, privacy information, and App Review Information. The policy layer covers how the app behaves, what it sells, how it handles user data, and whether its storefront implementation follows Apple’s rules.
A Capacitor application adds a specific complication. JavaScript and CSS may be cross-platform, but the iOS wrapper still has an Xcode target, native dependencies, entitlements, signing settings, and an embedded web asset set. A change to a plugin, URL scheme, push notification capability, or native configuration can turn a routine web release into a native release that must pass review.
Practical rule: Treat every submission as a reproducible release artifact, not as the latest folder on a developer’s laptop.
Apple’s review queue also affects release planning. Apple allows at most two submissions under review at the same time on a platform, one app version and one item such as an In-App Event, according to its submission guidance. Batching release-critical changes into one queue position creates avoidable risk. Stage the app version first, complete App Review Information before submission, and keep native changes separate from web-layer fixes where possible.
A web-layer fix can often ship through controlled live updates, provided it does not alter native capabilities or violate Apple’s rules. Native changes still belong in the normal review queue. Teams can document ownership, status checks, and response procedures with App Store review management, so a rejection produces a controlled fix instead of an emergency rebuild.
Prerequisites That Prevent Signing Failures
Signing failures usually start as configuration drift. The Bundle ID in App Store Connect differs from the Xcode target, a capability exists in the project but not in the Developer portal, or a CI machine has a certificate without the provisioning profile that authorizes it. Fixing these after an archive fails is slower than verifying them before development reaches release week.
Establish the account and ownership model
Confirm that the Apple Developer account is active and that the people responsible for releases can access both the Developer portal and App Store Connect. Teams often separate duties, so the person who manages certificates may not be the person who submits metadata. Write down who owns each action, especially if an agency, contractor, or startup founder is involved.
Create the App Store Connect app record before the upload. Select the correct platform, primary language, app name, bundle ID, and SKU. The bundle ID must match the identifier used by the Xcode target exactly. A record created with the wrong identifier can’t be repaired by changing a filename later.
Verify identifiers and capabilities
In the Apple Developer portal, inspect the App ID associated with the application. Enable only the capabilities the product needs, such as push notifications, associated domains, Sign in with Apple, or keychain sharing. Then compare those settings with Xcode’s Signing & Capabilities tab.
For Capacitor, check the identifier in capacitor.config or capacitor.config.ts, the iOS project target, and the app record. If you’ve changed the app ID, run the appropriate Capacitor synchronization command and inspect the native project instead of assuming the generated configuration updated every target.
Use automatic signing when the team wants Xcode to manage routine certificate and profile relationships. Manual signing can be appropriate for tightly controlled CI, multiple targets, or organizations with strict credential ownership, but it creates more objects that must remain aligned.
Run a release pre-flight
Before archiving, verify:
- Account access: The selected Apple team is the intended organization, not a personal or legacy team.
- Bundle identity: The Xcode target, Capacitor configuration, App ID, and App Store Connect record use the same identifier.
- Capabilities: Entitlements match the services enabled for the App ID.
- Distribution signing: The selected distribution identity is valid and available to the build environment.
- Provisioning: The profile corresponds to the correct App ID, certificate, and distribution method.
- Targets: Extensions, notification services, and other bundled targets use compatible signing settings.
- Secrets: CI has the required certificates and profiles without exposing them in the repository.
A successful development build proves that your team can run the app. It doesn’t prove that you can distribute it.
For teams managing several apps or environments, certificate ownership deserves its own process. Keep a record of expiration, responsible owners, renewal steps, and where profiles are installed. Capacitor certificate management is a useful reference for structuring that workflow without relying on one developer’s local setup.
Building and Signing Your Capacitor App for Release
The release archive should contain the web assets you intend to ship. In Capacitor projects, that means building the frontend first, syncing the native project, checking the iOS target, and only then creating the archive. Archiving an old www directory can produce a perfectly valid signed application with stale screens, missing fixes, or mismatched configuration.
Prepare the project before Xcode
A dependable sequence looks like this:
- Build the web application with the production configuration.
- Run
npx cap sync iosso native dependencies and web assets are aligned. - Open the workspace in Xcode, not an outdated project file.
- Select the intended app scheme and a generic iOS distribution destination.
- Confirm the marketing version and build number.
- Review Signing & Capabilities for the app and every extension target.
- Run a release build or archive.
The version shown in App Store Connect must correspond to the version configured in the Xcode target. The build number must increase for each uploaded artifact associated with that version. Keep those values in source control or generate them in CI, because manually editing them across several targets is an easy way to upload the wrong artifact.
If Xcode reports that it can’t find a provisioning profile, first confirm the team and Bundle ID. If it says the signing certificate is invalid, inspect the keychain on the machine performing the archive. If an entitlement is rejected, compare the .entitlements file with the capabilities enabled for the App ID. Don’t solve these errors by randomly toggling signing options. Find the mismatch.
Archive and inspect the artifact
In Xcode, choose Product, then Archive. After processing, open Organizer and select Distribute App, followed by the distribution path for TestFlight and App Store. Xcode will validate the archive before upload, but validation isn’t a substitute for testing the installed build.
Install the uploaded build through TestFlight and exercise the flows Apple is likely to inspect:
- First launch and onboarding
- Account creation and login
- Password reset or magic-link access
- Purchases and subscription restoration
- Camera, microphone, location, and notification permissions
- Deep links and external authentication
- Offline behavior and recovery after a failed request
- Any feature described in the screenshots or metadata
A Capacitor app can pass compilation while failing at runtime because the production backend URL, web asset path, native permission string, or plugin configuration differs from development. Test on a clean device or a clean simulator state, and test with the exact account details you’ll provide to App Review.
Teams without a reliable Mac release environment can use managed build infrastructure or CI. Automating Capacitor iOS builds with GitHub Actions can help formalize archive creation, signing, and artifact handling. For organizations hiring to own this process internally, iOS developer recruitment for startups provides context on finding engineers who can manage Swift, Xcode, signing, and release operations rather than only frontend implementation.
The video below is useful as a visual walkthrough of the Xcode portion of the workflow.
Before upload, inspect the archive’s identity, version, build number, included architectures, entitlements, and embedded assets. Keep the archive associated with its commit, web build, environment configuration, and release notes. When review raises a question, that traceability lets you answer precisely.
Uploading Testing With TestFlight and Completing App Store Metadata
Uploading the binary starts a controlled release process, not a finished submission. Xcode Organizer can send an archive to App Store Connect, while Transporter suits teams that prefer a separate delivery tool. App Store Connect processes the upload before the build appears in TestFlight or becomes available for version selection. Resolve processing delays and validation warnings before the release window becomes urgent.
Use TestFlight as a release gate
Install the processed build through TestFlight. A local Xcode launch can miss distribution-specific behavior, entitlements, and configuration differences. Internal testers can confirm core flows quickly. External testers help expose problems that people outside the App Store Connect team may encounter. Keep groups purposeful: a product group can validate feature behavior, while a release group checks upgrades, authentication, permissions, and crash-prone paths.
Beta notes should state what changed and where testers should look. Use the same evidence to prepare App Review Information. Supply a working demo account when login is required, explain setup steps, and identify features that are not obvious from the first screen.
Complete the product page as a package
Metadata makes promises that the binary must keep.
Prepare the app name, subtitle where applicable, description, keywords, screenshots, category, age-rating responses, privacy details, support URL, and marketing URL. Test every URL outside the development network. An internal VPN requirement, certificate error, or broken clean-device login can weaken an otherwise stable submission.
Screenshots should match the current interface and available functionality. Remove placeholder copy, debug labels, unfinished empty states, and environment-specific content. For multiple storefronts or languages, review each localized version rather than assuming translated strings are sufficient. The App Store metadata guide for developers provides a practical field checklist, but complete fields do not explain the product flow by themselves. Reviewers still need to reach the value shown on the product page.
Stage submissions deliberately
Treat the version submission and promotional items as separate release decisions. Submit the release-critical version first when the app fix controls availability. If an In-App Event is tied to that version, prepare its assets and dates alongside the release plan, then submit it only when the event can function with the reviewed build. This prevents a marketing item from becoming the reason a version package waits, while keeping related launch work traceable.
After App Store Connect processes the build, select it for the version, answer export compliance and content-rights questions, attach review notes, and submit. Record the submitted build number and exact metadata snapshot. If Apple asks which flow, account, or backend version the reviewer encountered, that record supports a precise answer.
For Capacitor teams, keep web-layer fixes separate from native release changes. A controlled live update can address eligible JavaScript or asset defects without sending every small web correction back through the native queue. Native code, permissions, plugins, and configuration still require the normal build and review path. That split turns submission into a rejection-resilience system: test the reviewed binary thoroughly, then reserve urgent resubmissions for changes that require native approval.
Handling App Review and Avoiding Common Rejections
The rejection data points to a practical conclusion: teams should spend less time guessing at obscure reviewer preferences and more time proving that the app is complete, functional, and accessible. Apple’s 2025 analysis recorded 1,354,418 performance-related rejection cases, and Apple’s App Review Guidelines require final versions with complete metadata, functional URLs, live backend services, demo access when necessary, and detailed notes for non-obvious features.
Make the submitted build resilient
A reviewer may encounter the app without your team’s context. If the first screen requires an account, provide usable credentials. If a subscription is hidden behind a particular navigation path, document it. If a hardware feature needs setup, explain the steps. If the backend has maintenance windows, schedule the submission around a period when the critical flows are available.
Performance issues are especially dangerous because they can appear only under real conditions. Test cold launch, slow networks, interrupted requests, large accounts, permission denial, and returning from background. A web-layer error inside a Capacitor shell can look like a native app defect to the reviewer, so capture frontend errors and native crash reports together.
Treat storefront rules as release inputs
Apple’s 2025 changes affected US storefront apps and altered rules involving buttons, external links, and calls to action for alternative purchase methods. Apple identifies the affected areas as Guidelines 3.1.1, 3.1.1(a), 3.1.3, and 3.1.3(a) in its announcement about those guideline changes. A monetization flow that passes one storefront’s assumptions may need different treatment elsewhere.
That doesn’t mean you should hide a purchase path from review. It means you should map the intended storefronts, payment flow, buttons, links, and explanatory copy before submission. The reviewer should see the same behavior your policy analysis expects.
| Rejection Driver | Preventive Action | Needs Resubmission |
|---|---|---|
| Incomplete app flow | Remove placeholders, finish onboarding, and test every advertised feature | Usually, if the binary behavior is incomplete |
| Broken login or unavailable backend | Provide working demo access and keep production services live during review | Yes, when the failure is inside the binary or service contract |
| Performance and stability problems | Test cold launches, network interruptions, permissions, and long-running flows | Usually, especially when native or bundled code changes |
| Non-obvious functionality | Add concise App Review notes with exact navigation steps | Not always, if the issue is only missing context and the build already works |
| Broken URLs or incomplete metadata | Validate privacy, support, marketing, and feature links from a clean environment | Yes, if the URL is embedded in the app or metadata cannot be corrected independently |
| Purchase and external-link policy mismatch | Review storefront-specific implementation against the current guideline sections | Usually, when buttons, links, or native purchase behavior must change |
Separate native fixes from web-layer fixes
For Capacitor teams, a rejection-resilience system should classify the fix before rebuilding. Changes to Swift code, plugins, entitlements, permissions, native configuration, embedded SDKs, or the app’s fundamental behavior belong in the normal App Store review queue. JavaScript, CSS, copy, and web assets can sometimes be delivered through a properly governed live-update mechanism, provided the update remains within Apple’s rules and doesn’t transform the app into something materially different from the reviewed product.
Capgo is one option for delivering signed web bundles to targeted channels, with staged rollout and rollback controls. That can reduce urgent resubmissions for a broken label, layout issue, or web-layer guard, while native changes still follow the ordinary review path. It isn’t a workaround for policy compliance. The submitted native shell and its declared functionality still need to be complete and reviewable.
Final Checks and Shipping Updates Without Resubmitting Everything
A reliable release loop ends with verification, not optimism. Before submission, confirm the version and build number, distribution signing, entitlements, processed TestFlight installation, clean-device smoke test, metadata, privacy and support URLs, reviewer credentials, purchase flows, and backend availability. Save the commit, archive, configuration, and review notes together.
After approval, watch crash reports, frontend errors, login failures, and support tickets. After rejection, read the Resolution Center message carefully, reproduce the exact issue, and reply with concrete navigation steps or submit a corrected build. If the rejection appears incorrect, use Apple’s communication and appeal channels rather than guessing at a silent workaround.
A live-update workflow can shorten the path for eligible web-layer corrections. App Store-safe OTA updates with Capgo describes the operational model: publish signed bundles to controlled channels, roll out to a selected audience, monitor adoption and failures, and retain rollback protection. Keep production releases narrow, test updates through a staging channel, and require a native submission whenever the change affects the reviewed native surface.
The sustainable cadence is simple: submit native changes deliberately, test every promised flow, and deliver eligible web-layer improvements through a controlled release system. That turns iOS app submission from a recurring fire drill into a release process the team can operate.
Capgo helps Capacitor teams deliver signed JavaScript, CSS, copy, configuration, and asset updates through targeted channels with rollout monitoring and rollback protection, while native changes continue through App Review. Visit Capgo to see how you can add that rejection-resilient update path to your iOS release workflow.
