How to plan an iOS App Store and Google Play submission and launch with a Gantt chart — from code freeze and QA through metadata, submission, and post-launch monitoring.
App store submissions have rejection rates that surprise teams who haven't been through the process before. Apple rejects approximately 40% of app submissions on first review — not because the apps are fundamentally flawed, but because metadata errors, privacy label inconsistencies, guideline violations in screenshot content, or broken functionality during Apple's review caught the reviewer's attention. Google Play rejections are less frequent but increasing as the platform tightens its data safety and content rating requirements.
A Gantt chart for an app store submission makes the submission process — and the weeks of pre-submission work that determine whether you sail through review or bounce back on rejection — explicit and sequenced. The teams that consistently get through review on the first pass have systematized the pre-submission checklist. The teams that consistently get rejected are improvising.
Code freeze and release candidate build: establishing a code freeze date is the starting gun for the submission timeline. After code freeze, the only changes going into the release candidate build are critical bug fixes — not new features, not "small improvements" that slip in at the last minute, and not dependency updates that haven't been tested. The release candidate build is the binary that will be submitted to the store.
QA testing at the release candidate stage covers a defined device matrix. For iOS, testing on the current iOS version and the prior major version on representative device models (current flagship iPhone, current iPhone SE or mid-range model, current iPad if the app is universal) is standard minimum coverage. For Android, OS fragmentation makes device coverage inherently broader — target the OS versions that represent 90%+ of your installed base and test on a physical device, not just an emulator, for at least the most common screen sizes.
Crash rate target: before submitting, review crash reporting (Crashlytics, Sentry, or the platform-native tools) and ensure the crash-free session rate is above your threshold — typically 99.5% or better for a production app. Submitting an app with known crash issues creates a high risk of post-launch user backlash and bad reviews during the critical first 72 hours of visibility.
Performance testing validates launch time (time from tap to interactive on cold start — Apple's guidance suggests under two seconds; anything over four seconds is a material UX problem), memory consumption under typical usage patterns, and battery drain. Performance problems caught pre-submission are far easier to address than those flagged in user reviews after launch.
Accessibility review: both Apple and Google require that apps meet baseline accessibility standards. For iOS, VoiceOver should navigate the app's primary flows correctly — every interactive element needs an accessibility label, and focus order should be logical. For Android, TalkBack serves the same function. Accessibility compliance is also increasingly required by enterprise customers and, in some sectors, by law (ADA compliance, Section 508 for government-connected apps).
Security review: a pre-submission security pass checks for common vulnerabilities — hardcoded API keys or credentials in the binary (tools like grep on the compiled strings table or automated scanning tools catch these), unencrypted local storage of sensitive data, insecure HTTP connections (App Transport Security on iOS blocks these by default, but exceptions can be carved out and need to be justified), and certificate validation.
Bundle ID and App ID registration in App Store Connect and the Apple Developer Portal must be completed before a build can be uploaded. If the app uses capabilities like Push Notifications, Sign in with Apple, or In-App Purchases, those entitlements must be configured in the portal and reflected in the provisioning profile.
App Store listing preparation has character limits that force deliberate copywriting. The app name is limited to 30 characters and is one of the most significant ASO (App Store Optimization) signals — include a keyword if it fits naturally. The subtitle (30 characters) is a second ASO field below the name on the product page. The description (4,000 characters) is not indexed by the App Store search algorithm but does appear when users tap to expand it. The keywords field (100 characters, comma-separated, no spaces) is the primary keyword field Apple uses for search indexing — research which terms your target users search for and use the full 100 characters.
Screenshot preparation requires providing screenshots at specific sizes. The required sizes as of current App Store guidelines are 6.7-inch (iPhone 15 Pro Max and Pro), 6.5-inch (legacy), and 5.5-inch (legacy iPhone 8 Plus); iPad sizes are required if the app runs on iPad. Mockup screenshots — device frames with call-out text overlaid — consistently outperform plain screenshots in conversion rate testing, because they communicate value at a glance without requiring the user to interpret raw UI.
App preview video (up to 30 seconds per locale) is optional but consistently improves conversion rates for apps where the value proposition is better demonstrated than described. The first three seconds are critical — many users don't tap play, so the video thumbnail needs to communicate value even when static.
Privacy policy URL is required for every app. The privacy policy must accurately describe what data the app collects, why, and how it's used. Apps with In-App Purchases or account creation functionality face higher scrutiny on privacy policy accuracy.
App Privacy Labels (Data Collection Disclosure) are Apple's structured privacy disclosure, required for every app. You must disclose every category of data your app or its third-party SDKs collect (analytics, crash data, location, identifiers, usage data, contact info, etc.), whether that data is linked to identity, and whether it's used for tracking. Third-party SDKs are the hidden landmine here — advertising SDKs, analytics SDKs, and third-party authentication SDKs all collect data, and you're responsible for disclosing their collection in your privacy labels. Getting this wrong is a rejection reason.
Store listing: title is limited to 50 characters, short description to 80 characters (displayed on the app's card in search results), and full description to 4,000 characters. Unlike App Store, Google Play's search algorithm does index the full description, making keyword placement in the description a meaningful ASO factor.
Screenshots and feature graphic: Google Play requires at least two screenshots; the feature graphic (1024×500px) appears as a banner in featured placements and in the store listing header when a video is present.
Content rating questionnaire (IARC): the International Age Rating Coalition questionnaire determines your app's content rating across all rating systems (ESRB, PEGI, USK, etc.). The questionnaire asks about violence, sexual content, language, social features, location sharing, and other content categories. Answering inaccurately is a policy violation; misrepresenting adult content with a family-friendly rating is a suspension risk.
Data safety form: Google's equivalent of Apple's privacy labels. You must disclose what data types are collected or shared, whether collection is required or optional, and whether the data is encrypted in transit and can be deleted by the user.
iOS review: submit the release candidate build through App Store Connect. Standard review times have historically been 24 to 48 hours for most apps, though complex apps or apps with new API usage can take longer. Expedited review is available through the Resolution Center for critical issues (security vulnerabilities in the production app, time-sensitive events) but should not be relied upon as a launch planning assumption.
Google Play review: new apps on Google Play typically take 2 to 7 business days for first review, longer than Apple's standard review. App updates to existing apps are usually faster (hours to 1 to 2 days). Google Play's automated systems catch many policy violations before human review, so clear rejections often come faster than approvals.
Rejection response buffer: build at least one week of buffer into the Gantt chart before the target launch date for handling a rejection. Common rejection reasons include guideline violations (usually fixable with metadata or UI changes, not code changes), broken functionality during Apple's review (test on a clean device with no prior app state), privacy label discrepancies, and missing permission usage descriptions in Info.plist.
Coordinated release: for apps targeting both iOS and Android, a same-day release on both platforms is strongly preferred for marketing simplicity. Submit to both platforms simultaneously, accounting for the different review timelines — submit to Google Play first if their review times are currently longer.
Push notification setup and testing: if the app uses push notifications, the notification delivery infrastructure (APNs for iOS, FCM for Android) needs to be tested with the production certificates and app identifier, not just in a development environment. Production push notification credentials are different from development credentials, and this is a common post-launch failure mode.
ASO monitoring: track keyword rankings in the first weeks after launch using ASO monitoring tools. Click-through rate on the store listing and the conversion rate (store listing visits to installs) are the key metrics to optimize iteratively through A/B testing of screenshots and copy.
First 72 hours monitoring: crash reporting, user reviews, and app store rating require active attention in the first three days after launch. A pattern of crashes from a device or OS configuration you didn't test can be identified early and addressed with a hotfix build if monitoring is active. Responding to early reviews — especially negative ones — signals to prospective users that the developer is responsive.
For development teams coordinating cross-functional app releases — engineering, design, QA, marketing, and legal — gantt-chart.io provides a shared timeline that makes every pre-submission task, review buffer, and launch-day action visible to every stakeholder.