App Store vs Play Store: what actually changes in the build.

Review process and timelines

Google Play review is usually fast — hours to a couple of days — and automated checks catch most policy problems. Apple's review is human-led for new apps and significant updates, often one to three days, and rejections can be appealed.

The practical difference: Play lets you iterate quickly and fix forward. Apple rewards getting it right before submission. A rejected iOS build can hold a marketing launch; a Play policy warning can usually be fixed with an update.

Billing and commissions

Both stores require their own billing for digital goods and subscriptions, and both take a commission (with reduced rates for smaller developers and for subscriptions after the first year). The details differ enough that "we will use the same payment gateway" is not a plan.

• Apple — in-app purchase required for digital content; physical goods and services can use external payment. External purchase link rules vary by region and change often.
• Google — Play Billing required for digital content; user choice billing exists in some markets. Physical goods and services are exempt.
• Both — subscription management, restore purchases and receipt validation are your responsibility, not the store's.

If your product sells both digital and physical things, the checkout has to route each correctly. That is a scoping decision, not a detail.

Privacy and permissions

Apple requires a privacy manifest, nutrition labels and explicit tracking permission. Account deletion has been mandatory for apps with account creation for some time. Google requires a data safety form and justification for sensitive permissions, and has been tightening background location and SMS access rules.

Both platforms now scrutinise third-party SDKs, not just your own code. An analytics or ad SDK collecting more than declared can fail review or trigger a policy issue.

Devices and fragmentation

Android runs on a huge range of hardware, screen sizes and OS versions. iOS runs on a narrow, predictable set of devices with fast OS adoption. That changes testing effort and performance priorities:

• Android needs low-end device testing, memory discipline and network resilience.
• iOS needs attention to the newest OS behaviour, safe areas and platform conventions.
• Tablets and foldables exist on both but are used differently; neither should be an afterthought if your audience uses them.

Release strategy

Play supports staged rollouts by percentage, which is genuinely useful for risk control. Apple supports phased release over seven days, which serves a similar purpose but with less granularity.

A sensible pattern: internal testing, a small external beta, a staged rollout to 10–20%, then full release once crash-free rate holds. Both stores support this; the mechanics differ.

Planning implications

• Budget more calendar time for iOS review, especially for the first release.
• Decide billing per product type before designing checkout.
• Write privacy declarations from the actual data flows, not from a template.
• Test Android on real low-end hardware; test iOS on the current OS.
• Keep store accounts in your own name, with the developer added as a user.
• Plan the release sequence so one store's rejection does not block the other.