Publish an App on Google Play and the App Store

This post compares the two, using each store’s own documents. It sits alongside our other studio notes, which begin with why some of our apps need no account. Where we use our own work as an example, the facts come from the product pages in our Store, and we describe nothing about the timing of any release.

What is the same

Both stores want a product that is complete, described honestly and backed by a privacy policy.

• A privacy policy. Apple’s guidelines say every app must link to its privacy policy in its App Store Connect metadata and within the app, and that the policy must say what data is collected, how, and for what. It must also explain retention and deletion. Google Play needs a privacy policy link to complete the Data safety form, even for apps that collect no user data.
• Accurate metadata. Apple asks that the description, screenshots, previews and privacy information reflect the app’s core experience and stay up to date. On Google Play, the listing has set limits: 30 characters for the app name, 80 for the short description and 4,000 for the full description.
• An age rating. Apple’s guidelines ask you to answer the age-rating questions honestly in App Store Connect.
• A support route. Each of our titles has its own privacy policy, terms of use and support page, whichever store it is reached from.

Review: what each store checks

Apple’s App Review Guidelines have five sections: Safety, Performance, Business, Design and Legal. A few rules shape most submissions. Section 2.1 expects final versions with all metadata and working URLs, no placeholder text, and an app that does not crash. Section 3.1.1 requires in-app purchase for unlocking features or content such as subscriptions and in-game currency.

Google Play’s help page for publishing describes a review summary. If it shows an errors summary, you cannot publish until the errors are resolved, while warnings do not block publishing. It also says that some developer accounts get a more thorough review, which can take up to seven days or longer in exceptional cases, and that managed publishing lets you decide when approved changes go live.

The practical lesson is to treat review as part of the schedule from the first day, not as a final step.

Testing routes: TestFlight and Play testing tracks

Both stores let you put a build in front of real people before everyone has it, in different shapes.

Google also states that developers with personal accounts must meet specific testing requirements before they can make an app available, and that these do not apply to personal accounts created before 13 November 2023. The details are on a separate Google page, so check it before you plan a launch date.

Privacy forms side by side

Each store asks you to declare what your app does with data, and each says the answers are your responsibility.

The two forms use different words for similar questions, so one set of notes written in your own terms saves time. For the reader’s view of these labels, see our guide to reading app privacy labels before you install. For how we describe analytics choices inside an app, see asking for analytics consent plainly.

Platform features that need separate work

A feature that looks like one idea can be two builds. Four common cases follow.

Widgets. Apple’s widget guidelines describe fixed size families on iPhone: small, medium and large, plus Lock Screen accessory shapes. Apple’s guidelines add that widgets refresh periodically and do not support continuous, real-time updates. Android’s overview describes sizes in grid cells that vary from device to device, and has separate pages for building them. Spareday shows the result: its page lists Home Screen widgets in two sizes and Lock Screen widgets on iPhone, and a 4x2 list and a 2x2 streak widget on Android. Our post on designing home screen widgets takes this further.

Notifications. Cardday’s page lists an optional daily study reminder, and on Android an optional daily word notification. The app has one idea of a reminder, and the platforms offer different ways to deliver it.

Purchases. Apple’s section 3.1.1 requires in-app purchase for subscriptions and similar unlocks. Cuelift, Spareday and Cardday each offer an optional Pro, and their support pages tell people to manage a trial through their Apple Account or Google Play, noting that Apple needs at least 24 hours’ notice. One offer, two sets of rules for cancelling.

Minimum system versions. Each product page lists a minimum version per platform. Spareday’s page says iOS 17.0 or later and Android 7.0 or later, and WisyLink’s says iOS 15.1 or later and Android 7.0 or later. Each platform has its own floor, set separately.

Why one store can move before the other

This section is general. It describes how the stores’ own documents make a launch uneven, and says nothing about any release of ours.

• Separate reviews. Each store reviews on its own terms and timing. Google describes some accounts getting a more thorough review of up to seven days or longer.
• Separate testing rules. Google’s testing requirements for personal accounts have no counterpart on Apple’s TestFlight page.
• Separate declarations. The two privacy forms are different forms, and each must be accurate for what that store distributes.
• Separate builds. A widget, a notification or a purchase flow is built once per platform.

Two stores mean two schedules, and a team has to plan each one.

A shared checklist for both

1. Write one privacy policy that names the data collected, how and why, and how to ask for deletion.
2. Keep one set of notes for the privacy declarations, in your own words, and answer each form from it.
3. Decide the age-rating answers once and apply them in both.
4. Check each store’s listing limits (Google Play, for example, allows 30 characters for the app name) and write text that fits both.
5. List every feature that touches the platform: widgets, notifications, purchases, permission prompts.
6. Start both testing routes early, and read each store’s account rules before fixing a date.
7. Read the review documents again before every release, because they change.

For our own routine before a release, see an app pre-release checklist.