Publishing to the App Store and Google Play

An app in a store always belongs to a developer account, and users see the account owner's name as the seller. So the first release question isn't technical: whose name goes on the account. Both platforms offer personal and organization accounts, with different requirements.

D-U-N-S is a nine-digit organization identifier in the Dun & Bradstreet database. According to Google Play Help it's free, but getting one can take up to 30 days, and paid intermediaries aren't needed. Plan for that time if the company doesn't have a number yet.

An app has three kinds of "names", and you shouldn't mix them up. The identifier, bundleIdentifier on iOS and package (applicationId) on Android, is unique in the store and never changes after publishing: a new identifier means a new app. The user-facing version (1.2.0) is shown on the listing. The build number (build number on iOS, versionCode on Android) is only for the stores and must grow with every upload.

According to the Expo docs, one common cause of store rejections is a duplicate build number: the developer forgot to bump it. That's why Expo recommends keeping build numbers on EAS servers (appVersionSource: "remote") and incrementing them automatically, while you change the user-facing version by hand for every release.

Signing proves that an update comes from the same developer. Android uses two keys: you sign the .aab with an upload key, and with Play App Signing Google re-signs the APKs with the app signing key it keeps. Play App Signing is required for new apps. If the upload key is lost or compromised, you can reset it in Play Console. On iOS you need a distribution certificate (shared by all apps in the account) and a provisioning profile for each app; profiles are valid for 12 months, but their expiry doesn't affect an app that is already published.

EAS Build produces signed .aab and .ipa files in Expo's cloud, and EAS Submit uploads them to Google Play Console and App Store Connect. Both work on macOS, Linux and Windows, so you don't need a Mac to ship the iOS version of an Expo project. Start with the identifiers in the app config.

{
  "expo": {
    "name": "Callback",
    "slug": "callback",
    "version": "1.0.0",
    "orientation": "portrait",
    "icon": "./assets/icon.png",
    "userInterfaceStyle": "light",
    "ios": {
      "bundleIdentifier": "kz.example.callback",
      "supportsTablet": false
    },
    "android": {
      "package": "kz.example.callback",
      "adaptiveIcon": {
        "backgroundColor": "#E6F4FE",
        "foregroundImage": "./assets/android-icon-foreground.png",
        "backgroundImage": "./assets/android-icon-background.png",
        "monochromeImage": "./assets/android-icon-monochrome.png"
      }
    }
  }
}

{
  "cli": {
    "version": ">= 18.0.0",
    "appVersionSource": "remote"
  },
  "build": {
    "preview": {
      "distribution": "internal",
      "android": {
        "buildType": "apk"
      }
    },
    "production": {
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {
      "android": {
        "track": "internal",
        "releaseStatus": "draft"
      },
      "ios": {
        "ascAppId": "1234567890"
      }
    }
  }
}

• cli.appVersionSource: "remote" and autoIncrement: true: EAS bumps versionCode and the build number on every production build.
• The preview profile builds an APK to install on the team's devices; Google Play doesn't accept APKs, the store needs an .aab, which the production profile builds by default.
• track: "internal" sends the build to internal testing, and releaseStatus: "draft" creates a draft release without rolling it out, which you finish in Play Console.
• To upload to Google Play, EAS needs a Google service account JSON key, added to EAS through the dashboard or eas credentials.

npm install --global eas-cli
eas login

# store builds: .aab for Google Play and .ipa for the App Store
eas build --platform all --profile production

# submit the latest build with the submit.production profile
eas submit --platform android --latest
eas submit --platform ios --latest

# or build and submit in one command
eas build --platform all --profile production --auto-submit

$ npx expo config --type public --json
{
  "name": "Callback",
  "slug": "callback",
  "version": "1.0.0",
  "sdkVersion": "57.0.0",
  "platforms": ["ios", "android"],
  "ios": {
    "bundleIdentifier": "kz.example.callback",
    "supportsTablet": false
  },
  "android": {
    "package": "kz.example.callback",
    ...
  }
}

After eas submit, the iOS build shows up in TestFlight once processed, and you submit it to App Review manually in App Store Connect. On Google Play the first submission creates a release on the internal testing track, but the app stays a draft until the store listing and the App content sections are complete.

In Flutter the version is one line in pubspec.yaml, and builds come from the Flutter CLI. The Android build is signed with an upload key through android/key.properties; iOS builds only on a Mac with Xcode.

version: 1.0.0+1

# Android: an App Bundle signed with the upload key from android/key.properties
flutter build appbundle
# output: build/app/outputs/bundle/release/app.aab

# iOS (macOS with Xcode only): an archive and an .ipa for App Store Connect
flutter build ipa
# output: build/ios/ipa/*.ipa, uploaded with Transporter or Xcode

Alternatives to EAS: a local build (eas build --local), Android Studio and Xcode by hand, and for CI tools such as Codemagic and fastlane, which the Flutter docs mention. The mechanics are the same everywhere: a signed artifact with a new build number is uploaded to the store console.

The listing is what users see before installing and what the reviewer checks first. The App Review Guidelines say plainly that metadata, including the description, screenshots and privacy information, must accurately reflect the app's core experience, and screenshots should show the app in use, not just the title art, login page or splash screen.

A privacy policy is a public page on a website, not a PDF sent by email. It describes what data the app collects, why, whom it shares it with and how users can delete it. App Privacy and Data safety answers must match the real behavior of the app and every library you include: analytics, ads, push notification SDKs. Google enforces against mismatches, and Apple expects you to keep answers up to date.

Apple says that on average over 40% of unresolved review issues relate to guideline 2.1, App Completeness. According to the same page, App Review typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours; incomplete submissions take longer. Google Play's help page on preparing for review doesn't name review times.

If App Review rejects a build, App Store Connect shows which guidelines weren't met, and you can correspond with App Review to resolve the issues before resubmitting. If you believe the app was misunderstood, you can appeal to the App Review Board: one appeal per rejected submission, with specific reasons. For Google Play the approach is the same: fix the app or the declarations in Play Console and send the corrected version for review again.

Every new binary goes the same way: a new build number, an upload, a review. Expo projects can deliver some changes over the air (OTA) with EAS Update: an app that includes the expo-updates library downloads a new JavaScript bundle and assets on its next launch.

npx expo install expo-updates
eas update:configure
# after a new build that includes expo-updates:
eas update --channel production --message "Fix login button alignment"

Next comes operations: watch crash reports in the store consoles, answer reviews and plan updates around Google Play's regular increases of the Android target API requirement. If the app uses push notifications, check the APNs keys and Firebase settings before release; there's a separate article on that.