Last updated: August 2026.
Publishing to Apple App Store and Google Play requires an eligible developer account, a tested signed build, accurate store assets, and review. Prepare each store separately and verify the release state. Review timing and required testing vary by account and app.
The App Store and Google Play each have their own account, signing, testing and listing requirements. Keep a checklist for each so an incomplete step in one console does not delay the other.
This guide walks through setup, testing, submission and updates. Build services can automate parts of that work, while the native consoles remain the place to confirm review and release status.
Set Up Your App for Both Stores
Start account enrollment and verification before you plan to submit the build.
Create your Apple and Google developer accounts
Apple requires you to enroll in their Developer Program that costs $99 USD yearly [1]. Organizations should complete several verification steps:
- A D-U-N-S Number to verify your organization's identity
- Legal entity documentation
- Website associated with your organization's domain
- Work email with your organization's domain [1]
Setting up a Google Play Console is simpler with a one-time fee of about $25 [1]. Both platforms show your developer name publicly, so pick it carefully. They also need two-factor authentication to keep your account secure [2].
Prepare your app assets and metadata
You'll need these key elements ready for both stores:
- Privacy Policy URL
- Support URL
- Marketing URL [3]
Choose screenshots for the device families your app supports using the current Apple sizes and Google Play asset requirements. Prepare the artwork in AppDrift’s screenshot editor, then check the exported files.
Check icon and preview-video specifications separately for each store. A valid screenshot size does not establish that an icon or video meets its own requirements.
Use a unified dashboard or CI/CD tool
Publishing integrations can reduce repeated work on supported listing fields. Choose one based on the tasks it actually handles.
When comparing tools, check whether they support the tasks you need:
- Track downloads, reviews, and TestFlight status
- Manage beta builds and testers
- View and respond to customer reviews [4]
Build automation tools can run tests and deliver builds after you configure the project and credentials. The CI/CD overview lists several options. Verify support for your stack and release steps before adopting one.
Configure Store-Specific Requirements
Image Source: Uxcel
Next, configure signing and permissions for each platform.
Apple App Store: Provisioning profiles and certificates
The Apple App Store uses digital signing with certificates to verify your app's authenticity. You'll need to create an App Store provisioning profile with an explicit App ID matching your bundle ID [6]. This profile includes a distribution certificate that serves as your digital signature.
You need these two essential components:
- Development certificates (for testing)
- Distribution certificates (for App Store submissions)
Only Account Holders and Admins can request distribution certificates [7]. These certificates expire after one year, so you'll need to renew them to continue uploading updates.
Google Play: App signing and Play Console setup
Google Play's App Signing manages your app's signing key on Google's infrastructure [8]. This system provides several benefits:
- Support for advanced delivery features like Android App Bundles
- Better security for your signing keys
- Knowing how to recover from lost or compromised upload keys [8]
You can choose between a Google-generated signing key or your own during the first release [9]. After that, you'll need to sign app updates with your upload key before submission.
Handle platform-specific permissions and policies
Both platforms have strict permissions models to protect user privacy. iOS requires usage descriptions in your Info.plist file to explain why you need each permission [10]. Users see these descriptions in permission request dialogs to understand your data usage.
Android groups permissions into "normal" (granted automatically) and "dangerous" (requiring explicit user approval) [11]. You must declare all permissions in your AndroidManifest.xml file.
Both stores need clear privacy policies that users can access within the app [12]. Apps trying to access sensitive data without proper permission declarations will face rejection during review.
Test and Distribute Before Publishing
Test the complete app before public submission, including login, payments, permissions and recovery from errors. If you are comparing supporting tools, keep the ASO tool guide separate from the store’s beta-testing requirements.
Use TestFlight for iOS beta testing
TestFlight offers an efficient way to gather feedback before launching on the Apple App Store. The platform lets you add up to 100 internal testers from your development team and up to 10,000 external testers [13]. Your builds stay active for exactly 90 days before they expire [14]. The TestFlight app makes it easy for testers to give feedback through screenshots, annotations, or comments about crashes they find.
Use Google Play Internal Testing tracks
Google Play internal testing supports a limited test audience after the required setup and processing. Verify availability in the console rather than promise delivery within seconds.
Generate install links for internal teams
Both platforms make distribution easier without managing individual device IDs. TestFlight allows you to invite testers through email or public links [13]. Anyone can join your beta through public links without needing email addresses, which removes barriers to participation [16]. Google Play sends direct invitations to testers through Google Groups or individual email addresses.
Manage test environments from one dashboard
A build service may deliver test versions to both platforms. Check which tester-management and feedback tasks it supports, then confirm the installed build works on real devices.
Publish and Manage App Updates
After testing, prepare each store submission. Listing management tools can help keep the text and artwork organized.
Submit to App Store and Google Play from one place
With paid access and completed setup, AppDrift Store Publishing can send supported listing text to connected stores. Use your build workflow for binaries and signing, and the consoles for review and release.
Track review status and feedback
Read review messages in App Store Connect and Play Console. Answer requests there and keep working reviewer access available until review is complete.
Push updates and manage version control
Each platform needs unique version identifiers. iOS uses CFBundleShortVersionString (user-facing) and CFBundleVersion (internal tracking), while Android needs versionName and versionCode [19]. Automated versioning tools can increase these values on their own, so you won't get rejected for duplicate versions [20].
Use metadata generation to draft release notes and descriptions from the actual changes. Review the draft before sending it.
Handle recovery and emergency fixes
Keep app-binary and backend recovery separate. You cannot instantly replace every installed mobile binary with an older version. Halt an eligible rollout where supported, prepare a corrected build, preserve backward-compatible server behavior, and follow the store review process. A backend deployment technique does not bypass app review.
Before automating an update, check the supported publishing setup. Apple screenshot uploads go to an App Store Connect draft; Google Play screenshots are exported for manual upload. Keep binary uploads and code signing in your build workflow, and confirm the public listing after release.
Key Takeaways
Keep the release checklist focused on these steps:
• Set up developer accounts early: Apple requires $99/year and organizational verification, while Google Play needs a one-time $25 fee
• Automate supported tasks, then confirm the result in each store console.
• Use TestFlight and Google Play Internal Testing for thorough beta testing before public release
• Keep version history and a recovery plan for both the app and its backend.
• Prepare accurate metadata and inspect each exported asset before submission.
Frequently Asked Questions
How much does it cost to publish an app on the Apple App Store and Google Play?
The Apple App Store requires enrollment in the Apple Developer Program at 99 USD per year. Google Play Store charges a one-time registration fee of approximately 25 USD. Both accounts give you access to billions of potential users worldwide. Apple's program includes access to developer tools, beta testing through TestFlight, and app analytics, while Google Play Console provides internal testing tracks and store listing experiments.
What are the key differences in app submission requirements between Apple and Google?
The stores use different signing systems, build formats and testing requirements. Their screenshot rules also vary by supported device family. Follow the current specifications linked above and verify the finished submission in each console.
Can I manage app publishing for both stores from a single dashboard?
Some tools handle builds, while others manage listing text, artwork or reports. Check the supported tasks and permissions rather than assuming one dashboard covers the entire release. AppDrift’s supported listing sending does not replace build uploads or review.
How can I test my app before publishing it to the app stores?
Use TestFlight and Google Play testing tracks to distribute eligible builds to testers. Setup, processing, review, and production-access requirements vary; an internal test does not automatically satisfy the rules for a new personal Google developer account.
How do I handle emergency fixes after an app has been published?
Plan recovery by component. Use eligible rollout controls, server-side mitigation where appropriate, and a corrected app build. Store-distributed binaries are not instantly reversible website deployments.
References
[1] - https://octopus.com/blog/modern-rollback-strategies
[2] - https://thisisglance.com/learning-center/what-app-store-assets-do-you-need-before-launch-day
[3] - https://www.viget.com/articles/submit-to-app-play-store
[4] - https://appnexus.app/
[5] - https://www.tlvtech.io/post/the-best-mobile-ci-cd-tools-for-faster-releases
[6] - https://developer.apple.com/help/account/provisioning-profiles/create-an-app-store-provisioning-profile/
[7] - https://developer.apple.com/support/certificates/
[8] - https://developer.android.com/studio/publish/app-signing
[9] - https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
[10] - https://cursa.app/en/page/handling-permissions-in-ios-and-android
[11] - https://developer.android.com/guide/topics/permissions/overview
[12] - https://www.iubenda.com/en/help/3744-how-to-add-android-and-ios-mobile-permissions-for-device-data-2/
[13] - https://developer.apple.com/testflight/
[14] - https://testflight.apple.com/
[15] - https://play.google.com/console/about/internal-testing/
[16] - https://developer.apple.com/videos/play/tech-talks/110343/
[17] - https://appcircle.io/blog/automate-app-store-deployment-to-app-store-google-play-and-huawei-app-gallery-with-appcircle
[18] - https://appradar.com/app-ratings-and-reviews
[19] - https://developer.android.com/studio/publish/versioning
[20] - https://docs.expo.dev/build-reference/app-versions/
