Publishing a Mobile App to the Apple App Store and Google Play

A step-by-step guide to getting an Expo / React Native app into both stores, for individual developers and for organizations (companies) using a D-U-N-S number. Committed was published this way; the same steps work for any app built on this stack.

Facts checked September 2026. Fees, review rules and deadlines change. Before you pay or submit, confirm anything marked verify in the live console or official help page linked next to it.

Read this with Most Common Reasons Apps Get Rejected from the App Store & Google Play (what reviewers reject) and the app's own STORE_SUBMISSION.md (listing text and privacy answers for that app).

Contents

1. Choose: individual or organization
2. Get a D-U-N-S number (organizations)
3. Apple Developer Program enrollment
4. Google Play Console registration
5. Prepare the app for release
6. Store assets you need
7. Build and upload with EAS
8. Apple: App Store Connect to release
9. Google Play: Play Console to release
10. After launch: updates, reviews, compliance
11. Timeline and cost summary
12. Troubleshooting

1. Choose: individual or organization

Decide this first. The account type determines the name shown on the store, the paperwork, and how long setup takes. Moving an app from an individual account to an organization later is possible but slow (Apple: app transfer; Google: app transfer request), so pick the one you'll keep.

Rules of thumb

• Publishing for a client? Publish under the client's organization account, and have them add you as a team member. Don't publish client apps on your personal account.
• Apple does not accept DBAs, trade names, branches or sole proprietorships as organizations. A sole proprietor enrolls as an individual.
• The organization's legal name must match exactly across the business registration, the D-U-N-S record, Apple and Google. Most delays come from a mismatch.

2. Get a D-U-N-S number (organizations)

A D-U-N-S number is a free nine-digit business identifier from Dun & Bradstreet (D&B). Apple and Google both use it to confirm your organization exists.

2.1 What to have ready

• Legal entity name, exactly as on your certificate of incorporation or registration
• Registered headquarters address (a real office address, not a P.O. box or registered-agent address)
• Mailing address if it's different
• Business phone number
• Work email on the company's domain (for example jb@desishub.com, not a Gmail address)
• Website on that domain, live and describing the business
• Your name and job title (you should have authority to act for the company)

2.2 Steps

1. Check whether you already have one. Use Apple's lookup tool (developer.apple.com → Account → enrollment → "Look up your D-U-N-S Number"). Many registered companies already have a number without knowing it.
2. If not, request one for free through the same Apple tool. The request goes to D&B.
3. Wait:
   • Apple route: D&B takes up to 5 business days to issue the number. Apple then needs up to 2 more business days to receive it. Plan for about 1–2 weeks. Paying for expedited D-U-N-S service doesn't make Apple's side faster.
   • Google: Google's help says getting a D-U-N-S number can take up to 30 days depending on your region. Start early.
4. Check the D&B record once issued: legal name, address and phone must match your registration documents. Fix differences with D&B before enrolling. After an update, allow a couple of business days for Apple and Google to see the change.
5. Use the same number for both stores.

If you're told your number "isn't found" after 2 weeks, contact D&B support through the link in Apple's D-U-N-S help page, not Apple.

Official: Apple – D-U-N-S Number · Google – Required information for a developer account

3. Apple Developer Program enrollment

3.1 Before you start (both types)

• An Apple Account with two-factor authentication on. For an organization, create a new Apple Account on the work email (for example apps@company.com) rather than using someone's personal account.
• Enroll from the Apple Developer app on an iPhone/iPad/Mac, or at developer.apple.com/programs/enroll. The app is usually faster for identity checks.
• A payment card for 99 USD (charged in local currency; renews yearly).

3.2 Individual

1. Sign in with your Apple Account and choose to enroll as an Individual / Sole Proprietor.
2. Enter your legal name and address as they appear on your government ID.
3. Verify your identity if asked (photo ID in the Developer app).
4. Pay. Membership usually activates within 48 hours.

3.3 Organization

1. Have your D-U-N-S number (section 2).
2. Choose Organization and enter:
   • legal entity name (exactly as D&B has it)
   • D-U-N-S number
   • headquarters address and phone
   • website on the company domain
   • work email on the same domain
3. Confirm you have legal authority to bind the organization to Apple's agreements. If you're not the owner or an executive, Apple will ask for someone who is. Apple may call to verify: answer the phone listed on the D&B record.
4. Pay once Apple approves. Approval typically takes a few days to two weeks.
5. In App Store Connect → Users and Access, invite your developers with the least access they need (Developer or App Manager). Keep Account Holder and Admin to trusted people.

3.4 Agreements, tax and banking

In App Store Connect → Business:

• Accept the Free Apps Agreement (automatic) and, if you sell anything, the Paid Apps Agreement.
• Paid apps also need tax forms (W-8BEN or W-8BEN-E for non-US entities, W-9 for US) and bank account details.
• Only the Account Holder can accept new agreements. When Apple updates them, submissions are blocked until they're accepted.

4. Google Play Console registration

4.1 Before you start (both types)

• A Google Account. For an organization, use one on the work domain and add team members afterwards. Don't publish from a personal Gmail you might lose.
• 25 USD one-time registration fee.
• A payments profile that matches the account type (individual or business).
• Android developer verification (verify): Google is rolling out mandatory developer verification. It is enforced first in Brazil, Indonesia, Singapore and Thailand from 30 Sep 2026, and globally from 2027. Google says it will register most Play apps automatically. Complete the identity steps the console asks for. Android Developers Blog

4.2 Personal account

1. play.google.com/console → Sign up → Yourself.
2. Enter:
   • developer name (shown on the store; may differ from your legal name)
   • legal name and address (taken from the linked payments profile)
   • contact email and phone (verified with one-time codes)
   • public developer email
3. Pay the 25 USD fee and upload a government ID when asked.
4. Closed testing requirement (personal accounts created after 13 Nov 2023):
   • Create a Closed testing track and add at least 12 testers (Google groups or email lists).
   • Testers must opt in through the link and stay opted in for 14 consecutive days. People who leave early don't count.
   • Then go to Dashboard → Apply for production and answer the questions about your test, your app and what you changed. Google usually replies within 7 days. Google – App testing requirements

4.3 Organization account

1. play.google.com/console → Sign up → An organization or business.
2. Enter:
   • D-U-N-S number
   • organization name and address
   • organization phone
   • organization website
   • contact name, email and phone
   • public developer email and developer phone (both shown on the store)
3. Be ready to upload:
   • business registration documents (certificate of incorporation, trade license or equivalent)
   • proof of the physical address
   • ID of the authorized representative, who must appear on the business registration
4. Payment verification may take a small deposit challenge or document upload (up to about 5 days).
5. No closed-testing requirement. You can publish to production once verification is complete, but still test on the Internal testing track first.
6. Invite team members under Users and permissions, with only the permissions each person needs.

5. Prepare the app for release

Do all of this before the first production build.

5.1 Identity and versions (app.json / app.config)

• Name ≤ 30 characters for Play; the app name on the home screen is short.
• iOS bundleIdentifier and Android package set once (for example com.company.app). They can never change after the first release.
• version (user-facing, for example 1.0.0). Let EAS manage build numbers: "appVersionSource": "remote" in eas.json and "autoIncrement": true on the production profile.
• Icons: a 1024×1024 PNG icon with no transparency for iOS, and an Android adaptive icon (foreground in the 66% safe zone plus a background colour).
• Splash screen image and background colour.
• ios.supportsTablet: false unless the layout is designed for iPad. Otherwise Apple reviews it on iPad and requires iPad screenshots.
• ios.config.usesNonExemptEncryption: false if the app only uses HTTPS/standard encryption. This skips the export compliance question on every upload.

5.2 Permissions

• Remove packages you don't use. Every native module can add permissions.
• Block permissions nothing uses in android.blockedPermissions (camera, storage, microphone, SYSTEM_ALERT_WINDOW, biometrics…).
• Every iOS permission you do need gets a clear purpose string tied to a visible feature.
• Ask for a permission at the moment the feature needs it, not at launch.
• Inspect the built APK: aapt2 dump badging app.apk | grep uses-permission.

5.3 Policy features both stores require

• Privacy policy on a public HTTPS URL, linked from the store listing and inside the app.
• Terms of use. For apps with user-generated content, the terms must state zero tolerance for objectionable content and abusive users.
• Support URL with a contact email.
• In-app account deletion if users can create accounts. It must delete server data, not just deactivate the account.
• Public web page to request account deletion. Google Play requires one.
• Report content and block users, if people can post or message each other (Apple Guideline 1.2). Reports must reach a real person, who acts within 24 hours.
• Sign in with Apple on iOS if you offer another third-party login such as Google, GitHub or Facebook (Apple Guideline 4.8).
• In-app purchases through Apple IAP and Google Play Billing for digital goods, with Restore Purchases.
• No tracking without App Tracking Transparency (iOS). Declare every SDK's data collection.

5.4 Technical requirements

• Android target SDK: new apps and updates must target API 36 (as of 31 Aug 2026, verify). Expo SDK 54 targets 36.
• 16 KB page size and 64-bit support for native libraries. Current React Native and Expo builds meet this.
• Release builds only, not debuggable. Android production uploads use an AAB (App Bundle), not an APK.
• A crash screen and crash reporting (an error boundary plus a global error handler that reports to your server, or Sentry). Without it, a crash on a reviewer's device leaves you nothing to debug.
• Production backend live and stable for the whole review, with seeded demo data.

5.5 Reviewer access

• A demo account that doesn't expire, needs no 2FA or email code, and already has realistic data.
• If the app needs other people (chat, teams), seed a second account that has already posted, so reviewers can test reporting and blocking.
• Step-by-step review notes: how to sign in, where each key feature is, anything that needs hardware or an external service.

6. Store assets you need

Screenshot rules: real screens from the current build, with real-looking data (no lorem ipsum). No claims like "#1" or "best". Text overlays are fine if they describe features that exist. No device frames of the wrong platform: no iPhone frames on Play.

7. Build and upload with EAS

7.1 One-time setup

npm i -g eas-cli            # or use npx eas-cli
eas login                   # the Expo account that owns the project
cd apps/expo
eas init                    # links the project, writes extra.eas.projectId

eas.json, typical profiles:

{
  "cli": { "version": ">= 16.0.0", "appVersionSource": "remote" },
  "build": {
    "base": { "env": { "EXPO_PUBLIC_API_URL": "https://api.example.com" } },
    "preview": {
      "extends": "base",
      "distribution": "internal",
      "android": { "buildType": "apk" }
    },
    "production": {
      "extends": "base",
      "autoIncrement": true,
      "android": { "buildType": "app-bundle" }
    }
  },
  "submit": {
    "production": {
      "android": { "track": "internal", "releaseStatus": "draft" },
      "ios": {}
    }
  }
}

7.2 Signing credentials

• Android: the first build offers to generate a keystore and stores it on EAS. Back it up (eas credentials → Android → download keystore). With Play App Signing (the default), Google holds the app signing key and your keystore is the upload key. A lost upload key can be reset through Play support.
• iOS: the first build asks you to sign in to Apple. EAS then creates the distribution certificate and provisioning profile, and enables capabilities from app.json (Sign in with Apple, push notifications). An organization account holder can create an App Store Connect API key (Users and Access → Integrations) so builds don't need someone's Apple password.

7.3 Test builds first

eas build -p android --profile preview      # APK to install directly on test phones
eas build -p ios --profile production       # then install through TestFlight

Install on real devices: a clean install, then an upgrade over the previous version, on at least one older and one current phone.

7.4 Production builds and upload

eas build -p android --profile production   # .aab
eas build -p ios --profile production       # .ipa
eas submit -p android --profile production  # uploads to the Play track in eas.json
eas submit -p ios --profile production      # uploads to App Store Connect / TestFlight

• Google: the first upload must be done manually in Play Console. After that, eas submit needs a Google service account JSON key with release permissions (Play Console → Users and permissions → invite the service account).
• Apple: eas submit uploads to App Store Connect. The build appears in TestFlight after processing (10–60 minutes).

8. Apple: App Store Connect to release

1. Create the app: App Store Connect → Apps → + New App. Enter the platform (iOS), name, primary language, bundle ID (must match app.json) and SKU (any internal id).
2. TestFlight:
   • Internal testers (up to 100 team members) can install right away.
   • External testers need a short Beta App Review (usually under 1 day). Add "what to test" notes.
   • Test the exact build you plan to submit.
3. App Information: category, content rights (does the app show third-party content?), age rating questionnaire. If users can chat or post, answer "user-generated content" honestly.
4. Pricing and Availability: price (Free), countries, and pre-order (optional).
5. App Privacy: privacy policy URL, then the data types questionnaire. List everything the app and its SDKs collect, whether it's linked to the user, and whether it's used for tracking.
6. Version page:
   • screenshots
   • promotional text, description, keywords
   • support URL, marketing URL (optional)
   • select the build
   • copyright (for example "2026 JB Web Developer")
   • version release: manual, automatic, or scheduled
7. App Review Information:
   • contact name, phone and email
   • demo account username and password
   • notes with step-by-step instructions (see section 5.5)
   • a short screen recording for hard-to-reach features (optional)
8. Submit for Review. Most reviews finish within 24–48 hours. Replies arrive in App Review messages.
9. If rejected: read the guideline cited. Fix the actual cause, reply in the same thread with what changed, and resubmit. For a metadata-only issue you can often fix the listing without a new build.
10. Release: manual release (you press the button), automatic after approval, or phased release over 7 days for updates.

9. Google Play: Play Console to release

1. Create the app: Play Console → Create app. Enter the name, default language, App or Game, Free or Paid (free apps can never become paid), and accept the declarations.
2. Set up your app (Dashboard checklist). Every item must be complete before release:
   • App access: "All or some functionality is restricted" → add the demo login and instructions.
   • Ads: does the app contain ads?
   • Content rating: IARC questionnaire. Say yes to user interaction if people can chat.
   • Target audience and content: age groups. Choosing under 13 brings Families policy obligations.
   • News app, COVID-19, government app, financial features, health: answer the declarations.
   • Data safety: every data type collected or shared, why, whether it's optional, whether it's encrypted in transit, and whether users can request deletion. This includes data from SDKs.
   • Account deletion: the public web URL where users can request deletion.
   • Privacy policy: URL.
3. Store listing: app name, short and full description, icon 512×512, feature graphic 1024×500, phone screenshots, category, contact email, and website (optional).
4. Testing tracks:
   • Internal testing: up to 100 testers, available in minutes, no review. Upload here first.
   • Closed testing: named testers or groups. Personal accounts need 12+ testers for 14 days here before production.
   • Open testing: public beta listing (optional).
5. Pre-launch report: after each upload to a testing track, Google runs the app on real devices and reports crashes, ANRs, accessibility and security issues. Fix what it finds.
6. Production release: Production → Create new release → add the AAB (or promote from testing) → release notes → countries/regions → staged rollout percentage (for example 20%) → Send for review. The first review usually takes a few days, sometimes up to 7.
7. Managed publishing (optional): approved changes wait until you press Publish.
8. If rejected: the email and Policy status page name the policy. Fix it, update the declaration, and resubmit. Use Appeal only if you believe the decision is wrong. A rejection notice may not list every problem, so recheck the whole app.

10. After launch: updates, reviews, compliance

• Every update: bump version for user-visible releases; EAS auto-increments build numbers. Write honest release notes, and test the upgrade over the live version.
• Staged rollouts: Play staged rollout and Apple phased release. Watch crashes before going to 100%.
• Crash and quality signals:
  • Play Android vitals: stay under the bad-behaviour thresholds for crashes and ANRs, or the app loses visibility.
  • App Store Connect Crashes and TestFlight feedback.
  • Your own crash endpoint or Sentry.
• Keep declarations true: when you add an SDK, analytics, login provider or new data, update the privacy policy, Data safety form and App Privacy labels in the same release.
• Moderation: answer reports within 24 hours and keep the support inbox monitored. Unanswered abuse reports are a common reason for removal.
• Yearly and policy deadlines:
  • Apple membership renews yearly; if it lapses, apps are removed from sale.
  • Google raises the target API level every year (usually due 31 August). Upgrade Expo SDKs in time.
  • Accept updated agreements promptly in both consoles; pending agreements block updates.
• Account security: 2FA for everyone, least-privilege roles, a shared role mailbox as account owner for organizations, and keystore and API key backups in a password manager.

11. Timeline and cost summary

12. Troubleshooting

Official references

• Apple: Enrollment · D-U-N-S Number · App Review Guidelines
• Google: Choose a developer account type · Required account information · App testing requirements for new personal accounts · Android developer verification · Developer Policy Center
• Expo: EAS Build · EAS Submit