You built your app. Now you need to get it in front of real users on the App Store or Google Play. Submission is where many first-time builders lose momentum because the process includes developer accounts, review guidelines, privacy details, screenshot specs, and review requirements that change over time.
Understanding the full pipeline before you start saves time, money, and rejected builds.
What it costs to publish on each platform
Cost is the first practical difference between the two stores, especially when you are validating an idea and want to keep fixed expenses low before launch.
Apple charges $99 per year for its Developer Program. Nonprofits, accredited educational institutions, and government entities may qualify for a fee waiver.
Google charges a $25 fee with no renewal.
Both platforms generally charge commission on in-app purchase revenue. Reduced rates may apply in some cases.
Google has the lower entry cost. That can make it a practical starting point if you want to validate your submission pipeline before handling Apple review.
How Apple App Store submission works
Apple submissions usually stall when account setup, metadata, screenshots, or the uploaded build are incomplete. Each phase has specific requirements that can delay or block your submission if you miss them.
Enroll in the Apple Developer Program
You need a paid account before you can submit anything. Go to the enrollment page or use the Apple Developer app. Individual enrollment requires an Apple Account with two-factor authentication. Your legal name must match your Apple Account exactly.
Organizations need a D-U-N-S Number, a work email on the company domain, and a publicly accessible website. The person enrolling must have legal authority to bind the organization.
Create your app record in App Store Connect
App Store Connect is where you manage metadata, screenshots, pricing, and submissions. Required fields include your app name, a permanent Bundle ID, privacy policy URL, age rating, and data collection declarations. You also need a description, keywords, screenshots, a support URL, and the app binary.
Prepare and upload screenshots
Apple accepts .jpeg, .jpg, or .png files only. You can upload up to 10 screenshots per device size. Screenshots must show your app interface. Text overlays are allowed.
Check size specs before uploading. Apple updates these when new devices launch.
Upload your binary and submit
The recommended path for most builders is the Xcode Product, Archive, Distribute App, and App Store Connect flow. Once your binary uploads and metadata is complete, click Submit for Review. Apple reviews every version, its metadata, and any in-app purchases.
How Google Play submission works
Google Play is more automated, but first submissions still fail on account verification, signing, listing details, and testing requirements. The process diverges from Apple in a few places, especially around testing and production access.
Set up your developer account
Register at Play Console and pay the $25 fee. Google requires developer verification for Play Console accounts.
Prepare and sign your app
Remove all debug logging and test data. Switch server URLs to production endpoints. Upload as an Android App Bundle (.aab), not a raw APK.
Apps distributed through Google Play using Android App Bundles require Play signing. Generate an upload key, sign your app, and let Google manage the actual signing key.
Complete your store listing and declarations
Your listing needs an app listing, screenshots, and a feature graphic. Complete the Data Safety section declaring all data collection and sharing practices. Link a working privacy policy.
Test before publishing
Testing is a gate for many first-time launches. Google offers three testing tracks: internal testing, closed testing, and open testing.
If your personal developer account was created after November 13, 2023, you need closed testing before publishing to production. For new personal accounts requesting production access, review times may take about a week or longer. Google recommends a 14-day wait before contacting support about delays.
Meeting these requirements gets your app into the queue, but it does not guarantee approval.
Where most first-time submissions fail
Most first-time rejections come from preparation mistakes, not obscure edge cases. Guideline 2.1 is a common source of App Store Review issues.
Incomplete or broken submissions
Crashes on real devices, broken links, placeholder text, and missing demo credentials for reviewers are common causes of rejection. If your app requires login, provide working test account credentials in your App Review Notes.
Privacy violations
Privacy declarations block many first submissions. Every permission request needs a specific, plain-language explanation. You must also offer an account deletion option if your app allows account creation.
Minimum functionality rejections
Apple may reject apps under Guideline 4.2 if they provide too little functionality or mainly duplicate a website experience without enough native app value. WebView-based output can create this risk. Your app needs enough native value for review.
Copycat or duplicate apps
Guideline 4.3 targets apps that closely imitate existing apps with minor differences. Before building, search the App Store for similar apps. Document your differentiators in your description, screenshots, and review notes.
On Google Play, app metadata must comply with store policies and may be subject to enforcement if it violates them. Choose a permanent package name carefully; it cannot be changed or reused after upload.
Privacy requirements you cannot skip
Privacy declarations are a submission gate on both stores. Your app, your store listing, and any third-party SDKs you use all need to align, and that is often what blocks first-time launches.
Apple privacy declarations
Every submission requires a completed App Privacy section in App Store Connect, covering all data types collected by your code and any third-party SDKs. If your app, or any third-party SDK it uses, accesses Apple privacy-relevant Required Reason APIs, you must include a privacy manifest. This requirement took effect on May 1, 2024.
Apps must comply with Apple privacy disclosure requirements for data collection and third-party SDKs. A privacy policy mention alone is not sufficient.
Google Play data safety
The Data Safety form in Play Console is mandatory. Without it and a linked privacy policy, your listing cannot be published.
Both stores require your privacy policy to be publicly accessible, linked from your store listing, and reachable from within the app itself.
What AI app builders need to know
What matters most is not whether you used AI during development, but what the shipped app does after installation. Review risk changes with the runtime behavior of the shipped app, not with the tools you used to build it.
Runtime code generation risks
Apps built using AI tools during development are treated like any other app. Apps that execute generated code after installation face higher review risk.
Platform checks before you commit
For AI app builder platforms, verify three things before committing:
- The platform produces iOS output that fits store requirements, not just progressive web apps
- Its Android support matches your launch plan
- Its submission workflow fits the store process you plan to use
If any of these are missing, your submission may stall before a human reviewer sees it.
A faster path from build to App Store
Anything currently supports iOS deployment through App Store submission via Expo with cloud-signed submission steps. Android is still in development, so you still need a separate path for Android submission until that support ships.
You still need your own Apple Developer account ($99/year) and must meet the privacy and metadata requirements covered above. Anything handles part of the build pipeline. You handle the store listing, privacy declarations, and review process.
If you are ready to build your app and ship it to the store, get started and focus on what makes your app worth downloading.
