App Store vs Google Play: A Side-by-Side Guide for App Teams

If you ship one app on iPhone and Android, you run two release processes. The steps rhyme, since both stores have an account, a beta channel, a review, a gradual rollout and a place to answer reviews, but the limits, fees and names differ at nearly every step. This page puts them side by side as of 7 October 2026 and links our guide for each half. Use it as a map, then follow the links for the detail.

The short version

• Apple charges 99 USD per membership year. Google charges a one-time US$25 registration fee.
• New personal Play accounts must run a closed test with 12 testers for 14 days before production. Apple has no equivalent rule.
• Apple reviews most submissions within a day or two. Google warns that review can take up to seven days, or longer in exceptional cases.
• Apple's phased release runs on a fixed seven-day schedule. Google's staged rollout runs at the percentage you choose, until you raise it.
• Both stores ration the system rating prompt, so neither is a channel for feature requests.

The two stores side by side

Facts are from Apple's and Google's own pages, as of 7 October 2026. Each row links our App Store guide and its Google Play twin.

Two Play topics have no Apple twin. Google's target API level rule means new apps and updates must target Android 16, API level 36, from 31 August 2026. And Android developer verification starts protecting users from 30 September 2026 in Brazil, Indonesia, Singapore and Thailand. If you also publish outside Play, see Galaxy Store and AppGallery and the Amazon Appstore on Fire devices.

Where the differences bite

Accounts and launch day

The money is the smaller difference. The bigger one is time. Apple's enrolment page asks organisations for a D-U-N-S Number, which you may have to request and wait for, while Google's testing requirement for new personal accounts adds at least two weeks of closed testing before you can apply for production. If you plan a launch on both stores the same day, start the Play closed test while your iOS build is still in TestFlight.

Fees

Apple's Small Business Program sets a 15% commission for eligible developers, and you have to enrol. Apple's terms differ by region: new EU terms took effect on 1 October 2026, set out on Apple's EU apps page, and Apple announced a 12% rate for Small Business Program members on the China mainland storefront from 15 March 2026. Google's service fees page changed this year too: from 30 June 2026 in the EEA, UK and US, and from 30 September 2026 in Australia and Japan, the fee depends on whether a user's install is new or existing, and a 5% billing fee applies to purchases through Google Play Billing. There, auto-renewing subscriptions, and earnings up to US$1M a year, carry a 10% service fee. Read both pages for your own markets before you set prices.

Review and rollout

Apple's App Review page sets expectations of a day or two for most apps. Google's publishing page says review times can reach seven days or longer in exceptional cases, so leave more room on the Play side for a dated launch. Once approved, the rollouts work differently. Apple's phased release follows a fixed seven-day schedule that you can pause, while Google's staged rollout stays at the percentage you set until you raise it, and you can halt it.

Ratings and replies

Both stores ration the system rating prompt. Apple's ratings page allows the prompt up to three times in a 365-day period, and Google's In-App Review API enforces a time-bound quota and says not to trigger it from a call-to-action such as a button. For replies, Apple's help page shows one response per review, and Google's Reply to Reviews API caps a reply at 350 characters. Neither prompt nor reply is a good place for a feature request, which is why both of our guides suggest pointing people somewhere they can add it or vote for it.

Release notes and assets

Apple's version information allows 4,000 characters of release notes, while Google's release notes allow 500 per language. Draft the Play version before the Apple one: if the change people asked for fits in 500 characters, the App Store version is easy. For assets, Google's preview assets page sets the 512 pixel icon and the 1024 by 500 feature graphic, which has no App Store counterpart. Apple's screenshot specifications list the display sizes it currently asks for.

One codebase, two store workflows

Cross-platform frameworks share your code, not your release process. Each store still needs its own build, signing, listing and review.

Flutter

Flutter's deployment docs have one guide per store: Build and release an Android app and Build and release an iOS app. You build an app bundle for Play with flutter build appbundle and an archive for App Store Connect with flutter build ipa. The version comes from the version line in pubspec.yaml: a version name, a plus sign and a build number. On Android it sets versionName and versionCode; on iOS the build name becomes CFBundleShortVersionString and the build number CFBundleVersion. Keep that one line as the source of truth, so a bug report from either store maps to the same version. For icons, the Android guide points to the flutter_launcher_icons package, or to placing the adaptive icon files by hand.

React Native and Expo

React Native's guide to publishing to the Google Play Store builds an Android App Bundle with npx react-native build-android --mode=release, which runs Gradle's bundleRelease. If you use Expo, EAS Submit uploads a signed .aab to Google Play and a signed .ipa to App Store Connect from the command line. For Android, it needs a Google Service Account key with access to your app, the same kind of credential our Play API service account guide covers.

Kotlin Multiplatform

JetBrains' guide to publishing a Kotlin Multiplatform app says Kotlin Multiplatform has no obvious effect on building the Android app: the shared module and the app are typical Android Gradle modules, so you publish to Play as you would any Android app. The iOS app is built from a typical Xcode project, so publishing it follows Apple's usual steps. In practice, the store work is the same as for two native apps; what you share is the code underneath.

How FeedbackKit fits in

Two stores give you two sets of reviews, but your users ask for the same things on both. FeedbackKit lets one project serve both builds. Every SDK, including Swift, Kotlin, Flutter and React Native, is configured with your project's API key and talks to the same API, so you can put the same key in your iOS and Android builds. A request filed on an iPhone and a vote cast on an Android phone land on the same row, and the six statuses are the same on both: Pending, Approved, In Progress, TestFlight, Completed and Rejected.

FeedbackKit's beta status is called TestFlight, after Apple's service, and Android users see that same label. Many teams use it to mean "in testing", whichever store's beta it is, so a request can sit in TestFlight while the iOS build is in TestFlight and the Android build is on a Play testing track.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

When a request ships on both stores, the people who asked can hear about it from one place; closing the loop with status emails covers how. Pricing lists what each plan includes. To put one board behind both stores, start free.