How to Set Up a React Native App for Dual-Store Publishing in 2026

Published: July 11, 2026

Version française →

Shipping a React Native app to both the App Store and Google Play sounds manageable until you're actually doing it. Then you're in two tabs — App Store Connect and Google Play Console — copy-pasting metadata between them, resizing the same screenshot six times, and second-guessing whether the title you just wrote hits the 30-character limit or the wrong one.


What dual-store publishing actually involves

Two upload buttons would be nice. In practice it breaks into four separate workstreams: build artifacts (a signed .ipa for Apple, a signed .aab for Google), metadata (title, subtitle/short description, long description, keywords, category), screenshots (device-specific images at each store's required resolutions), and ongoing operations (reviews, version updates, phased/staged rollouts). Building with Flutter instead? The Flutter version of this guide swaps the raw Xcode and Gradle commands below for flutter build ipa and flutter build appbundle.


Step 1: Configure your React Native project for both platforms

iOS: provisioning and .p8 setup

You need a valid App Store distribution certificate, a provisioning profile tied to your bundle ID, and an App Store Connect API key (.p8) for automated uploads. Store the .p8 somewhere secure — a vault encrypted at rest, not just HTTPS in transit.

cd ios
xcodebuild -workspace YourApp.xcworkspace -scheme YourApp -configuration Release -archivePath build/YourApp.xcarchive archive
xcodebuild -exportArchive -archivePath build/YourApp.xcarchive -exportPath build/ipa -exportOptionsPlist ExportOptions.plist

Android: keystore and service account JSON

You need a release keystore and a Google Play service account JSON with androidpublisher scope, edit and publish access. Build with cd android && ./gradlew bundleRelease, output lands at android/app/build/outputs/bundle/release/app-release.aab. Keep both the keystore and the service account JSON out of version control.


Step 2: Write metadata once, publish to both stores

The two stores don't share field names, character limits, or keyword strategy.

  • Title — 30 characters, on both stores.
  • Subtitle / short description — 30 on the App Store, 80 on Google Play.
  • Long description — 4000 characters, on both.
  • Keywords — a dedicated 100-character field on the App Store; Google Play has no such field, the description text is what gets indexed.

The 30-character title is the tightest constraint, so write that first — but since both stores cap it at exactly the same length, one title usually works for both, no need to trim it for one and stretch it for the other. Long description is different: Google Play indexes the description text for search while the App Store doesn't, so the Play description should work keywords in naturally, while the App Store one is free to just sell the app.

A shared doc works fine for one app. It breaks down at two. OneStore's editor shows live character counters for both stores at once as you type.


Step 3: Handle screenshots without Photoshop

Apple requires at least one of three iPhone formats — 6.5" (1242×2688), 6.7" (1290×2796), or 6.9" (1320×2868) — not all three. 6.7" is the current standard format: Apple auto-scales a 6.7" screenshot to fill the 6.9" preview slots, so an app that only ships 6.5" or 6.7" shots still clears review. iPad 12.9" (2048×2732) is only required if the app declares iPad support. Google Play has its own set: phone, 7" tablet, 10" tablet.

Design at the highest resolution and let a tool handle resizing — OneStore takes one HD source image and outputs every required format.


Step 4: Upload binaries to both stores

iOS upload via Apple Transporter

xcrun altool --upload-app --type ios --file build/ipa/YourApp.ipa --apiKey YOUR_KEY_ID --apiIssuer YOUR_ISSUER_ID

Transporter.app does the same thing with a GUI. The binary lands in App Store Connect's processing queue.

Android upload via the Google Play API

Authenticate with the service account JSON, create an edit, upload the bundle, assign it to a track (internal/alpha/beta/production), commit.


Step 5: Manage the rollout

Apple and Google don't work the same way here, and it's a common source of confusion.

Apple's phased release is fully automatic and controlled by Apple: 1%, 2%, 5%, 10%, 20%, 50%, then 100% over 7 days. It only kicks in from version 2 onward — never on the initial submission. OneStore shows the current stage on the release timeline and links back to App Store Connect if you want to pause or adjust it; OneStore doesn't control that percentage itself, Apple does.

Google Play's staged rollout is genuinely controlled from OneStore: set the rollout percentage, monitor it, halt it, resume it, push to 100%, and promote a build across tracks (internal → production) without re-uploading — all from the dashboard, no need to go back to Play Console.


Step 6: Set up review management across both stores

Both stores generate reviews independently — checking manually means two consoles open at once. A unified inbox that surfaces both in one place, with AI-drafted replies in the reviewer's language, removes the context-switching.


Step 7: Keep listings in sync after launch

Listings drift after launch — someone edits directly in a console, and your source of truth is quietly wrong. Drift detection diffs each store's live listing against what's in your tool when you open the editor, flagging changes before you overwrite a real edit or publish stale copy.


Putting it together

The build side is well-documented; the operational side — metadata, screenshots, uploads, reviews, rollout — is where the time actually goes. OneStore covers metadata, screenshots, binary uploads, review management, and rollout in one place. The free plan covers 3 apps, no card required, both stores included. AI credits are only spent on optional features like translation and review replies — connecting stores, editing listings, and publishing stay unlimited and free on every plan.

The Store Listing Audit tool (no account, no email) scores an existing listing out of 100.


FAQs

Does OneStore work with Expo-managed React Native apps?

Yes, it's framework-agnostic — build the .ipa/.aab your normal way, upload through OneStore.

What's the difference between the App Store and Google Play title limits?

None — both cap out at 30 characters. One title usually works for both stores.

Can I use phased rollout for the initial launch?

Not on Apple — phased release only applies to updates, never to the initial submission; the first release goes to 100% immediately once approved, and phased release only kicks in from version 2 onward. On Google Play, though, you can start your very first production rollout at a reduced percentage from day one.

What happens if I edit my listing directly in a console after connecting OneStore?

Drift detection flags the difference the next time you open the editor.

Do I need a Mac to build the .ipa?

Yes, Xcode requires macOS (or a macOS CI runner); the upload step can happen from anywhere once you have the file.

Is my service account JSON stored securely?

Yes: credentials (the .p8 key, the service account JSON) are stored in a vault encrypted at rest with AES-256-GCM at the application layer. A Data Processing Agreement based on the EU Standard Contractual Clauses is available on request at onestore.so/dpa.

What tracks can I publish to on Google Play through OneStore?

Internal testing, closed testing (alpha), open testing (beta), production — with staged rollout percentage control on each.