App Store Submission Checklist: Google Play and iOS

To submit a mobile app you need a developer account on each store, a release build signed with your own keys, a complete store listing, accurate privacy and data declarations, test access for the reviewers, and a plan for staged release. Android apps go through the Google Play Console; iOS apps go through App Store Connect. Both stores publish detailed, changing policies, so treat this article as a general checklist and confirm the current rules in each store's own documentation before you submit. We do not quote fees or policy details here because they change.

Before you start: accounts and ownership

• Register a developer account with each store under your company, not under a developer's personal name. Accounts tied to one individual are a common source of trouble when people leave.
• Check the registration requirements and any verification steps in the Google Play Console and Apple's developer programme pages. Verification of an organisation can take time, so start early.
• Decide who holds the account owner role, and keep the recovery details somewhere safe.
• Store your signing keys and certificates securely, with a backup. Losing them can make future updates difficult.

Prepare the build

• Test the exact release build, not only the debug build. Behaviour can differ.
• Remove test settings, debug logging and hard-coded test servers.
• Set the app name, bundle or package identifier, version number and build number deliberately. The identifier cannot be changed after publication.
• Check that you target the operating system versions the stores currently require for new submissions. Both stores raise these requirements over time, so look at the current notes in each console.
• Confirm the app runs on a range of real devices and screen sizes, and on the oldest operating system version you claim to support.

Prepare the store listing

Item	Notes
App name and subtitle or short description	Clear, honest, within each store's character limits
Full description	What the app does, written for users, not a keyword list
Screenshots	Real screens of the shipping app, in the sizes each console asks for
App icon	Meets each store's size and format rules
Category and content rating	Answer the questionnaires truthfully
Support contact and website	A working email and a real support page
Privacy policy URL	Live, accurate and reachable without logging in

Do not use another brand's name or imagery, and do not show features the app does not have. Misleading listings are a common reason for rejection.

Privacy and data declarations

Both stores require you to declare what data your app collects and how it is used. Google Play asks for this in the Play Console; Apple asks for privacy details in App Store Connect. The answers must match what the app really does, including what third-party SDKs collect. Go through the app and every SDK to build an accurate list before filling in the forms. If you handle personal data of people in the EU, your privacy policy should also reflect your obligations under GDPR. This is general information, not legal advice; the Data Protection Commission is the official Irish source.

Give the reviewers what they need

• If the app needs a login, supply a working demo account and any steps needed to reach the main features.
• If the app depends on a hardware device, a specific location or a paid account, explain how to test it in the review notes.
• Make sure your server is running and reachable during review.
• Explain any permission the app requests and why it needs it.

Test before you submit

1. Use each store's testing tracks. Google Play offers internal, closed and open testing tracks, and Apple provides TestFlight for beta builds.
2. Test a fresh install, an upgrade from the previous version, and a logged-out start.
3. Check behaviour with poor or no connection; see offline-first mobile apps explained.
4. Check that permission requests appear at sensible moments and that denying them does not crash the app.
5. Run through account creation and deletion, if your app offers accounts.

Release and monitor

• Use a staged or phased rollout where the console offers one, so a serious bug reaches fewer users first.
• Set up crash reporting before release so you can see problems quickly.
• Prepare a support route and a plan for urgent fixes.
• Keep the release notes accurate. Describe what changed in plain words.
• Plan the first few updates in advance; see mobile app maintenance after launch.

One-page pre-submission list

1. Developer accounts active under the company, with ownership documented.
2. Signing keys backed up securely.
3. Release build tested on real devices.
4. Listing text, icon and screenshots complete and truthful.
5. Privacy policy live; data declarations match actual behaviour.
6. Content rating questionnaires answered.
7. Reviewer demo account and notes supplied.
8. Server and APIs ready for reviewer access.
9. Crash reporting enabled.
10. Rollout plan and support contact ready.

Understanding the review from the stores' point of view

App review exists to protect users. Reviewers check that the app does what the listing says, works without crashing, handles personal data responsibly and follows the rules for content, payments and permissions. Thinking like a reviewer helps you pass. Open your own app on a clean device with no prior setup and try to use it as a stranger would. If you get lost, a reviewer might too.

What to do if the app is rejected

1. Read the rejection message carefully, and note which guideline or policy it cites.
2. Fix the specific issue. Do not guess at unrelated changes.
3. If the message is unclear or you believe it is a mistake, use the console's reply or appeal route politely, with evidence such as steps and screen recordings.
4. Resubmit, and record what happened so the next release goes smoother.

Rejections are common for first releases and are usually fixable quickly. They are not a sign the project has failed.

In-app purchases and subscriptions

If your app sells digital goods or subscriptions, each store has its own rules about how payment must work and what must be disclosed to users. These rules are detailed and change, so read the current policy text in the official documentation before you design the purchase flow, not after. If the app only gives access to a service customers bought elsewhere, or sells physical goods, different rules may apply. Check the store's current guidance for your case.

Keep a release record

For every submission, record the version, build number, date, what changed, and who approved it. When something breaks in production, that record shortens the investigation considerably.

Common mistakes

• Submitting on launch day. Review time is unpredictable; leave a buffer.
• No demo account. A reviewer who cannot sign in cannot approve the app.
• Inaccurate privacy answers. Forgetting what an SDK collects is a frequent cause of rejection or later removal.
• Placeholder content. Lorem ipsum text, broken links and empty screens look unfinished.
• Personal developer accounts. Transferring ownership later is harder than starting right.
• Not reading the current guidelines. Rules change, and what was accepted last year may not be accepted now.

Need a hand with release?

Submission is a small part of the project, but it has sharp edges when done for the first time. Soch Tech's mobile app development service covers Android and iOS builds, and long-term support after launch, so you do not have to learn the stores' quirks the hard way.