Guide

Publishing an app to the App Store and Google Play: what to prepare.

Finishing the code is not the same as being in the stores. Both Apple and Google require accounts, listings, privacy disclosures and a review before customers can download your app, and each can send it back. Planning for these steps early saves weeks at the end. Policies and fees change, so check the current requirements before you commit to a date.

Key takeaways

Open developer accounts in your company's name, early. Verification can take time.
Prepare the listing, screenshots and privacy disclosures in parallel with the build.
Review is outside anyone's control. Allow days of margin, and expect an occasional rejection.
Read the store policies before designing payments, sign-in and account deletion.
Publishing is the start: updates and compliance continue.

Accounts: do this first

One developer account per store. Apple and Google each run their own programme, with fees and identity checks that can take days or longer, especially for companies.
Register as the company, not an individual or the developer. If the supplier's name is on the account, the app is theirs to withdraw or move. See choosing a development partner.
Check what the stores need from a company, such as a legal entity name, a business identifier and a person with authority to accept the terms.
Give the team access, not ownership. Add developers as users with the roles they need.
Protect the accounts with strong sign-in and more than one administrator.

The listing

Name, short description and full description, in each language you support. In Hong Kong that usually means English and Traditional Chinese. Write them for people, not just for search.
Icon and screenshots at the sizes each store requires for the device types you support. Screenshots in both languages convert better than one set for everyone.
Category, age rating and contact details, including a support address that someone actually reads.
A public privacy policy at a web address, in the languages you list. See our PDPO guide.
A demo account and notes for reviewers if the app needs a login to see its main features.

Privacy disclosures and policy checks

Data declarations. Both stores ask what data the app collects, why, and whether it is shared, including through third-party components you use. Your developer has to inventory these accurately; wrong answers can lead to rejection or removal.
Permissions. Ask for camera, location or notifications only when needed, and explain why at the moment you ask.
Account deletion. Apps that let people create accounts are expected to let them delete the account from within the app. Plan this feature.
Payments. Selling digital goods or subscriptions inside an app is governed by store rules, which affect which payment methods you may use. Check them before designing the flow.
Sign-in options. Offering third-party sign-in may bring requirements to offer others. Read the current guidelines.
Content and behaviour. User-generated content, health or finance features and children's audiences have extra rules.

These are general pointers. The policies are long and updated often: read the current text on each store's developer site.

Testing before release

Use the stores' testing channels to share builds with testers before public release. They let you check installation, updates and real-device behaviour.
Requirements for testing before a first public release can apply, especially to new accounts. Check the current rules, and allow time for them.
Test on real devices across screen sizes and recent operating-system versions, and on weak connections. See mobile apps.
Plan a staged release where possible: a small share of users first, then everyone, so a serious problem is caught early.

Review, rejection and what to do

Review takes anything from hours to several days. It is not fixed and not negotiable. Submit well before any launch date, and avoid promising one publicly until approval.
Rejections are common for first submissions. The usual causes are crashes, missing demo access, inaccurate privacy answers, unclear permission requests, incomplete features and payment rule breaches.
Read the message carefully, fix the specific point, reply clearly and resubmit. Where you disagree, you can ask for clarification or appeal through the store's process.
Keep a record of what was submitted and what was said.

After you are live

Reply to reviews, especially the unhappy ones. They are public and read by prospective users.
Keep up with the stores. New operating-system versions and policy changes can require an update to stay listed.
Watch crash and usage reports, and release fixes quickly.
Plan the upkeep. See maintenance and support.

Keep reading

Check your readiness with the launch readiness checklist.

Frequently asked questions

How long does it take to get an app approved?

It varies, from hours to several days, and first submissions are often sent back at least once. Plan a margin of a week or more before a fixed date, and check the stores' current guidance.

Can we avoid the stores with a web app?

Yes. A web app needs no store approval and can be updated at once. It cannot do everything a native app can. See native, cross-platform or web.

Who should own the store accounts?

Your company. The supplier should be a user with the access they need, so you can change supplier without losing the app, its reviews or its users.

Planning an app launch?

Tell us what the app does and when you want it live. We will map the steps, including the ones outside our control.

Request a project quote