You built your app and it works on your screen. Now you need Apple or Google to approve it. This step, the submission and review process, is where many first-time builders stall. This article walks through the requirements you need to complete before hitting submit. You will learn what stores ask for before review and which details can block approval.
Both stores now host 4 million apps combined. Official review data shows 90% of submissions reviewed in less than 24 hours. Speed does not help if your submission bounces. Preparation is what usually decides whether review moves forward.
Why most first submissions get rejected
This section covers the rejection patterns reviewers check first. It matters because most of them are avoidable before submission. After this, you will know which problems to catch before a reviewer does.
Apple lists several common App Store rejection categories, including performance, metadata, legal, design, business, and safety issues. Privacy policy issues are also a common problem on Google Play, and missing or broken privacy policy URLs can violate Google Play policy requirements.
Both stores also review metadata for accuracy. Screenshots must match the product. Descriptions must not overstate functionality. Category selections must fit the core use case. Apple also flags low-value apps that duplicate what already exists without meaningful differentiation.
Reviewers look for a working product, complete submission details, and an honest presentation of what the app does. Perfection is not the bar. The next section covers what Apple requires before you submit.
What Apple requires before you submit
Apple expects the submission record to be filled out correctly before review can move forward. After this, you will know what to prepare before you upload your build. The submission process includes account setup, metadata entry, visual assets, privacy declarations, and a build upload. Each step has specific fields and formats. Missing required information can block your submission.
Account and app record setup
You can not submit to Apple until your developer account and app record are set up. That is the practical first step because the rest of the submission depends on it. Start by enrolling in the Apple Developer Program. Free accounts exist but can not publish apps. Enrollment takes time, so budget lead time before your launch date.
Create an app record in App Store Connect after enrollment. You will set your Bundle ID, target platforms, and public developer name. If you distribute in the EU, Apple may require your Trader Status information.
Metadata that reviewers verify
Reviewers compare your metadata to the product they test. Inaccurate or incomplete fields can trigger rejection even when the build works.
Complete the required parts of your app record. Your app name and app icon are separate elements in App Store submission. Your privacy policy URL and support URL must both be live and working when reviewers check them.
Do not include competitor brand names in metadata and do not overstate what the app does.
What to check before you submit
This final check pulls the article together. It matters because most approval problems in this article come from a small set of avoidable mistakes. After this, you will know what to review before you send your build for approval. Check the build first. Make sure the app works, the screens are not empty, and any backend services stay available during review.
Then check the submission record. Make sure metadata matches the product. Confirm links work and privacy details are in place. Make sure the app does not present itself as more capable than it is.
That is the practical pattern across the article. A working app is necessary, but it is not enough. Approval usually depends on whether the build, metadata, and required links line up when review starts. If you want a practical next step, review your build and submission record together before you upload anything. That usually gives you the clearest picture of what could block approval.
Most submission problems come down to three things: a build that does not work as described, metadata that does not match the product, and missing or broken policy links. Fix those before you upload, and you remove the most common reasons reviewers reject first-time submissions.
Start by walking through your build and submission record side by side. Confirm every screenshot reflects the current product. Verify that your privacy policy URL and support URL both load. Then check that your app description matches what a reviewer will actually see when they open the app.
If you are ready to build and ship your app, start building with Anything and get from idea to submission faster.
