Publishing an app to the App Store and Google Play: a practical checklist

To publish an app, you need a developer account with Apple and one with Google, both in your own or your company's name. You then upload a signed build, fill in the store listing and the privacy forms, test the build with real users through TestFlight and Google Play testing tracks, and submit it for review. Most rejections come from crashes, incomplete information, privacy answers that do not match the app, or missing access for the reviewer, and all of these can be checked before you submit. After approval, release updates gradually so a bad build reaches as few people as possible.

#Set up the accounts and signing keys in your name

Developer accounts

Apple publishes apps through the Apple Developer Program and App Store Connect. Google publishes through the Google Play Console. Both let you enroll as an individual or as an organization. If the app belongs to a company, enroll as the company: the developer name shown in the store is the account holder, and moving an app between accounts later takes extra work. Apple asks organizations for a D-U-N-S number, and Google asks for verification details, so start early.

• Invite your developers or agency as users with limited roles. Do not give them the account holder login.
• Keep the payment and tax details, the agreements and the contact details up to date. Either store can pause publishing when an agreement has not been accepted.

The same rule applies to everything around the app: the code repository, the backend hosting and the domain. Our article on who should own the code and the accounts explains what to check before and at handover.

Signing keys

Every build is signed so the store and the phone can confirm it comes from you.

• iOS uses certificates and provisioning profiles tied to your Apple developer account. They can be reissued from the account if needed.
• Android uses a keystore. With Play App Signing, Google keeps the key that signs the app on users' devices, and you sign uploads with a separate upload key. If you lose the upload key, the account owner can ask Google to reset it. If you manage the app signing key yourself and lose it, you cannot publish updates to that app.

Store keystores and passwords in a password manager or secrets vault controlled by your company, and write down where they are. Never leave them only on one developer's laptop.

#Write the store listing and prepare screenshots

The listing is what users read before they install, and reviewers check it against the app.

• App name, subtitle or short description, and a full description that says what the app does in plain words.
• Screenshots for the required device sizes, taken from the real app. Both stores publish the current size requirements; check them for each release instead of reusing old images.
• An app icon, a category, keywords (App Store) and a feature graphic (Google Play).
• An age rating, completed through each store's questionnaire.
• A support URL and a privacy policy URL that load and describe this app.

#Complete the privacy disclosures and the data safety form

Both stores ask what data the app collects and why. On the App Store these answers become the app's privacy details. On Google Play they go into the Data safety form. You answer for the whole app, including third-party code: analytics, crash reporting, advertising, login providers and payment SDKs all count.

1. List every kind of data the app or its SDKs collect: contact details, location, identifiers, usage data, crash logs and payment information.
2. For each, note whether it is linked to the user, whether it is used for tracking, and whether it is shared with third parties.
3. Make sure the privacy policy says the same things as the store forms.
4. If users can create an account in the app, give them a way to delete it. Both stores require this.
5. On iOS, ask for tracking permission with Apple's App Tracking Transparency prompt before tracking users across other companies' apps and websites, and write clear text for every permission prompt (camera, location, contacts).

Update these answers whenever you add an SDK or a feature that collects new data.

#Test with real users before release

TestFlight is Apple's beta testing service. Internal testers are members of your App Store Connect team and can install builds as soon as they are processed. External testers are invited by email or by a public link, and the first build for external testing goes through a short beta review.

Google Play has internal, closed and open testing tracks. Internal testing reaches a small list of people quickly. Closed testing reaches the groups you invite. Open testing lets anyone join from the store listing. Google requires some newer personal developer accounts to run a closed test with a minimum number of testers for a set period before they can publish to production, so check the current rule when you create the account and plan for it.

Use testing to check the things reviewers and users will hit first: sign-up and login, payments or subscriptions, push notifications, permission prompts, and what happens with a slow or missing connection.

#Avoid the common rejection reasons

Store rules change and are published in Apple's App Review Guidelines and Google Play's Developer Program Policies. The reasons below come up often, and each can be checked before you submit.

• Crashes and broken flows. The reviewer opens the app on a real device. If it crashes, freezes or shows an error on the first screen, it will be rejected.
• No access for the reviewer. If the app needs a login, provide a working demo account and any instructions in the review notes.
• Placeholder or incomplete content. Lorem ipsum, empty screens, dead links and "coming soon" sections suggest the app is unfinished.
• Too little functionality. An app that only wraps a website, with nothing that uses the device, is often refused.
• Payments for digital content. Selling digital goods or subscriptions inside the app usually has to go through the store's own billing system. Physical goods and services use your own payment provider. Read the current rules for your case before you build the checkout.
• Privacy mismatches. Data the forms do not declare, a missing privacy policy or unclear permission prompts.
• Misleading metadata. Screenshots, descriptions or names that do not match the app, or that use other companies' brands without permission.

If a review is rejected, read the message carefully, fix the specific point, and reply in App Store Connect or the Play Console. Both stores have an appeal process when you believe the reviewer made a mistake.

#Release gradually and keep updating

After approval, choose how the release reaches users. Google Play supports staged rollouts: you release to a percentage of users, watch crash reports and reviews, then increase it or halt it. On the App Store, a phased release spreads an automatic update over several days, and you can pause it if something goes wrong.

Publishing is not a one-time event. Both stores raise their minimum requirements for new operating system versions and SDKs, and an app that stops receiving updates can be hidden from new users. Plan for regular maintenance releases, and keep the API behind the app compatible with older versions still on people's phones. If you are still choosing a framework, our comparison of React Native and Flutter covers how that choice affects maintenance.

#How PN Scripts can help

PN Scripts builds iOS and Android apps with React Native, Flutter, Swift and Kotlin, along with the API behind them, and handles the store releases. The developer accounts, the signing keys and the code stay in your name from day one. See how a project runs on our mobile app development page.