1. Prepare the app’s identity

You need the appropriate Apple Developer access, an app record in App Store Connect and a unique bundle identifier such as com.company.product. Keep that identifier consistent between your project and Apple’s configuration. It is not simply the name shown beneath the app icon.

Prepare the public name, category, age-rating answers and support and privacy URLs. Doing this early exposes dependencies while you can still resolve them calmly, instead of discovering them when the build is already waiting.

2. Create a production build

For a local React Native iOS build, Xcode provides the native build and archive workflow. With Expo, EAS Build can produce a signed iOS build using your chosen production profile. Follow the documentation for your project’s workflow rather than mixing steps from unrelated tutorials.

Before building, verify the visible version, build number, app icon, permission descriptions and production service URLs. Record the commit and configuration. A successful compilation does not establish that the app is talking to the right backend.

  • Use an explicit release configuration.
  • Keep private credentials out of the JavaScript bundle.
  • Record which build your testers actually installed.

3. Upload, then wait for processing

You can upload an Xcode archive through Organizer or use EAS Submit for the Expo workflow. The command eas submit --platform ios starts the iOS submission flow. Uploading makes a build available for processing in App Store Connect; it does not, by itself, release the app to customers.

Read processing messages before producing another build. A question about configuration or export compliance may require information in App Store Connect, while an incorrect binary requires rebuilding. Keep the distinction clear to avoid repeating the same upload.

4. Test the release candidate

Install through TestFlight on a device that is not relying on your development environment. Test a cold start, first-use permissions, links, connectivity errors and the support route. If your app includes purchases, include their relevant test flows too.

Start with a small internal group, then include people outside the project. Ask for an observable result. Someone failing to understand the first action is a useful finding even when no crash appears in the logs.

5. Make the listing match the app

Your title, description and screenshots should show what this build actually does. Avoid screenshots from an unfinished redesign or promises about planned features. Review the privacy answers against the data used by your own code and the services you have integrated.

Open support and privacy URLs without an administrator session and check every active localisation. In the BeSafe experience described in this guide, a broken public URL in the configured localisations contributed to a Guideline 1.5 rejection. The listing belongs in your release checks.

6. Submit and keep the review trace

Select the tested build, complete the required submission information and provide usable review access where needed. Explain how to reach features that are not obvious. Review notes should help someone operate the app, not read like advertising.

If a rejection arrives, preserve the message, reproduce the issue and connect the correction to a specific check. Explain where the reviewer can verify it. This record becomes a practical checklist for your next release.