Publishing on the App Store and Google Play is not just uploading a file. The stores check the product, the documents and how you described the app on its listing. If you haven't prepared accounts, access, legal texts and release files in advance, you almost always lose time on fixes and resubmissions.
This checklist helps a business get through the publishing stage with less stress. You'll understand exactly what to prepare before review, who on the company side should be involved and where rejections usually come from.
What to understand before submitting your app to the store
Why review checks the product and the metadata together
The store checks more than how the app works. It compares the actual functionality with what you wrote in the title, description, screenshots and promo materials. If a screenshot shows a feature that isn't in the build, you risk a rejection. If the app asks for permissions and doesn't explain why, you also risk being turned down.
Think of review as matching promises against facts. The app must do what you claimed. And the store listing must show what the user will see inside.
Which roles you need from the business and the development team
It's important for the business to appoint a single person responsible for the release. They gather the materials, keep the deadlines, approve the final texts and answer review questions.
Usually you need these roles:
- the product owner or business owner, to confirm the monetization model, limitations and audience
- marketing, to prepare the texts and visuals for the app listing
- a lawyer or the person responsible for documents and consents, to close the questions on privacy policy and data processing
- the development team, to assemble release builds and prepare signatures, certificates and testing data
- QA, to check the critical scenarios before submission
If you haven't locked in the roles, the team starts arguing as early as the build upload stage. And the store doesn't wait.
How much time to budget for review and fixes
Review always involves waiting and iterations. Budget time not only for the review itself, but also for fixes and resubmission. This matters especially if your release is tied to an ad campaign, an event or commitments with partners.
Don't plan the launch with no buffer. Preparing accounts, documents and release materials often takes more time than the final build.
Developer accounts and access you need to prepare in advance
Apple Developer and App Store Connect: what the company will need
To publish an iOS app you need an Apple Developer account and access to App Store Connect. From the company side you usually need to prepare data that confirms who owns the account and who is authorized to publish the app.
Before you start publishing, check:
- who owns the account and whose details it is registered under
- who has access to App Store Connect and can answer review questions
- who can sign agreements in the dashboard if you plan to monetize
If you don't have an account, don't put off registration until the last week. This step often blocks the entire release.
Google Play Console and developer profile settings
For an Android release you need access to Google Play Console. In the developer profile you fill in the data the user sees. And this data also affects trust and review.
Before uploading the build, check:
- whether the developer details and contacts are filled in
- whether there is a working support email
- who will administer the console and who can manage releases and test tracks
If you change the owner or access at the last moment, you risk losing control over the release.
Team access and secure storage of data
Give the development team and QA access by role. Don't use one shared login. This reduces the risk of losing the account and of mistakes during publishing.
Separately set up secure storage for:
- console access credentials
- certificates and signing keys
- release files and store materials
- test credentials for the reviewer
Losing signing keys or confusion over access almost always turns into a costly delay.
Legal requirements and documents without which publishing will be stopped
Privacy policy and support page
The stores expect the user to be able to read what data the app collects and where to go for support. You need a privacy policy on a public page. You also need a clear support page with contacts.
Check two conditions:
- the policy opens via the link and works on a phone
- the support contacts match those listed in the app card
If the links lead to a blank page or a meaningless document, you lose time on resubmission.
Collecting and processing personal data and consents
If the app collects personal data, you must explain this to the user. Show what data you collect, why you do it and how the user can manage it.
In practice it's important to agree in advance on:
- what data you actually collect in the app
- which permissions you request and why
- what consent text you show the user and exactly when
Don't add unnecessary fields to registration. Don't request access without a reason. Review pays attention to this.
Copyright, licenses and the use of third-party content
If you use other people's texts, images, music, video or brands, prepare proof of rights. This applies to content inside the app as well as materials in the app card.
Before the release, check:
- whether you are using materials without a license
- whether you are creating the impression of a connection to another brand when there is none
- whether you are copying visual elements that could be misleading
It's better to remove questionable content before submission than to explain it after a rejection.
Preparing the build and release artifacts
iOS: certificates, profiles and the build for upload
For iOS publishing, the certificates and profiles that link the build to your account matter. The development team must prepare the build so that App Store Connect accepts it and can process it.
Before uploading, check:
- the team is using the right account and the right signatures
- the build has no test settings that break things for the reviewer
- you know which build you're sending to testing and which to release
If you change critical settings right before submission, you raise the risk of errors while the build is being processed.
Android: signing key and build formats
An Android release requires a correct signature. This is the key that links the app to future updates. Losing the key blocks the normal growth of the product.
Before publishing, check:
- where the release key is stored and who has access to it
- which build format you prepare for uploading to the console
- that you use the same signing scheme for all releases
Don't pass keys around in chats and don't keep them in open access. That's a risk for security and for the release.
Versioning, environment and what not to change at the last moment
The store and users expect predictable releases. If you change the environment, the API, domains or critical settings right before submission, you get instability, authorization errors and payment problems.
Before the final build, lock down:
- the release addresses of servers and integrations
- analytics and notification settings that affect the user flows
- the list of permissions and screens the reviewer will see
The final build must be exactly the version you are ready to show the user.
App quality before publishing
Stability on a weak connection and across different devices
The reviewer checks the app like an ordinary user. They may run it on an unstable network. They may switch between Wi-Fi and mobile data. They may minimize the app and come back a minute later.
Before submission, check the behavior in three modes. Good internet. Bad internet. No network at all. The app should show clear messages and not freeze.
Next, check different devices and screen sizes. Don't rely only on a single flagship phone. A common problem is broken layout on a small screen. Another common problem is buttons that are hard to hit.
Also check the scenarios after an update. The user may install the new version over the old one. Data must not disappear. Authorization must not break.
Checking critical scenarios: registration, payment, access recovery
The store most often rejects apps not for minor bugs. It rejects them because the user can't get through a key path. So you must run the critical scenarios before submission.
A minimum list to check:
- registration and login, including errors and re-login
- access recovery if the user forgot the password
- completing a purchase or subscription if you monetize the app
- access after payment, so the user sees the result right away
- account deletion if the app creates accounts
Don't leave stubs and 'coming soon' screens in the release. If you write about a feature on the app listing, the user and the reviewer must see it in the build.
Crash logs, analytics and a minimum monitoring setup
Set up basic diagnostics before publishing. You need to understand where the app crashes and what exactly breaks for the user. Without this you will be guessing the reasons for rejections and complaints.
Check three things:
- the app writes crash logs and you can read them
- the app has basic analytics of key actions, so you can see where people drop off
- you record network errors and server responses that affect registration and payment
If the reviewer hits an error, you must be able to reproduce and fix it quickly. This saves days of back-and-forth and re-review.
Related service
We'll prepare the release and handle publishing on the App Store and Google Play
We'll set up accounts, access, builds and metadata, check the critical scenarios and legal texts, prepare test tracks and go through review together with you — so the release doesn't slip because of rejections.
Content for the app listing and the rules of accuracy
Title, description, key elements and forbidden wording
The app listing is part of the review. The store compares the texts with what the product actually does. So write only about what exists in the current version.
Put together the basics of the listing in advance:
- a title that clearly explains the essence
- a short value statement in the first lines
- a full description with a clear structure and no excessive promises
- support contacts that match your pages and emails
Avoid wording that sounds like unprovable claims. Don't promise what you can't show in the app. Don't describe future features as already working.
Icon, screenshots and video: what must match the functionality
Visuals must show the real interface. Screenshots and video can't be a designer's fantasy. They must match what the user will see after installation.
Check before uploading:
- the screenshots are taken from the current build
- the images don't show features that aren't in the app
- the texts on the screenshots don't contradict the rules and aren't misleading
- the icon doesn't copy other people's marks and doesn't create a false impression of a link to another brand
If you change the interface at the last moment, recapture the screenshots. A mismatch is a frequent cause of fixes and rejections.
Localization: when you need it and how not to ruin the texts
Localization is needed when you publish the app for several markets or show the app listing in different languages. The store and users expect the texts to be readable and accurate.
Don't do localization in a rush. A common mistake is machine translation without review. It breaks the meaning and reduces trust.
Check at least:
- the title and description sound natural in each language
- the terms in the app and on the listing match
- no text in another language is left on the screenshots if it matters for understanding
If you're not ready for quality localization, it's better to start with one language and expand after the release.
Publishing settings and test tracks
TestFlight: internal and external testing on iOS
TestFlight helps you test the iOS build before the release. It reduces the risk that the reviewer is the first to see a critical bug.
Set up two levels:
- internal testing for the team, to catch errors quickly
- external testing for a limited group, to see the behavior of real users
Prepare clear instructions for the test. Give testers specific scenarios. Collect feedback in one place. That way you close errors faster before submitting to the App Store.
Test tracks in Google Play and pre-release check requirements
In Google Play it's more convenient to roll out builds through test tracks. You can check the app on real devices and Android versions before you open access to everyone.
Set up the tracks in advance:
- an internal track for the team
- a closed track for a group of testers
- if needed, an open track for a wider check
Budget time for pre-release testing. Google may require testing before full publishing. If you don't plan this stage, you risk shifting the release date.
Age rating, categories and content questionnaires
Before publishing, the store will ask you to pick a category and fill in content questionnaires. These answers affect the age rating and availability in different countries.
Check the consistency:
- the content in the app matches the chosen rating
- the description and screenshots match the same content level
- you honestly indicate the presence of user content, ads or purchases if they exist
Don't understate the rating for reach. This is a frequent cause of problems already after publishing.
Monetization and purchases: where rejections happen most often
Subscriptions and in-app purchases: transparency of terms and price
If the app sells digital access, review looks closely at the payment screen and the wording. The user must understand what they are paying for.
Check what you show before the purchase:
- the exact price
- the billing frequency if it's a subscription
- the terms for canceling and managing the subscription
- the difference between the trial period and the paid part, if you offer one
Don't hide the terms in fine print. Don't change the price in different places. The price in the app must match what the user sees in the store.
Restoring purchases and access after payment
After payment the user must get access right away. If you keep showing a paywall or don't unlock the features, review considers this an error.
Check two scenarios:
- immediate access after a successful purchase
- restoring purchases on another device or after reinstalling
Make the restore button noticeable. Test the scenario on test accounts. This reduces the risk of rejection and complaints after the release.
Allowed payment methods and typical rule violations
The stores tightly regulate payment methods for digital goods and subscriptions. A frequent reason for rejection is an attempt to take the user to external payment where the store requires the built-in one.
Before the release, agree with the team on:
- what products you sell, physical or digital
- what payment scenarios exist in the app
- where the links from the app and from the store card lead
If you add payment through a website, check that the store rules allow it for your model. If not, remove this scenario before publishing.
What to do if your app is rejected and how to pass re-review
How to read the rejection reason and build a list of fixes
A rejection almost always comes with a reason and a reference to a rule. Read the whole message. Don't pull out a single phrase. The store often points to several problems.
Right away, collect the list of fixes in a single document:
- what exactly the reviewer didn't like
- where it is — the screen, the link, the section in the card
- who fixes it — development, design, content, the lawyer
- what you will check after the fix so the problem doesn't come back
Don't make fixes blindly. Reproduce the scenario the reviewer described. If you can't repeat the problem, it means you don't have enough data or you're checking the wrong path.
How to prepare an explanation for the reviewer and test data
If the reviewer can't get through a scenario, they will reject the app even with working code. Give them a way to check the product.
Prepare:
- a test account if the content is only available after login
- test data so the reviewer sees the features you are responsible for
- short instructions on how to go through the key scenarios — registration, purchase, access recovery
- contacts to reach you if the reviewer asks for clarification
Write the explanation in plain words. State what you fixed, where to check it and on which build version. Don't argue. Show that you understood the rule and complied with it.
How to organize the release after approval and updates without risk
After approval you get the temptation to quickly push an update and finish the small things later. That way you often get a new rejection on the very next version.
Put together a minimum release plan:
- who presses the publish button and when
- which metrics you check in the first hours — installs, registrations, purchases, errors
- how you make decisions on an urgent hotfix — who is responsible and where the access lives
- how you keep a list of changes and versions so you don't lose control
Don't change critical things on release day. Don't update texts and visuals chaotically. Keep the app card and the product in sync. Then subsequent updates go more smoothly.
