Everything You Need in Place Before You Launch Your App

What store reviewers reject and how to prevent it

The gap between "app works on my device" and "app approved on both stores" has ended more launch timelines than any engineering bug.

If you're figuring out how to launch an app, the technical build is only part of the work. Store metadata, privacy declarations, analytics wiring, and rollback plans determine whether your first week generates traction or generates fires.

Start with the listing itself. On Google Play, fastlane supply expects a versionCode that strictly increments, a package name that matches your build.gradle, and metadata files for every locale you target: title.txt, short_description.txt, full_description.txt, plus screenshots per device type.

On the App Store side, fastlane deliver reads CFBundleVersion and CFBundleShortVersionString from your Info.plist. Apple requires a privacy nutrition label that matches your actual data collection, not what you plan to collect someday.

A mismatch between your declared App Tracking Transparency usage and your actual SDK calls is one of the rejection reasons we've run into most often across projects.

Run fastlane supply --validate_only and fastlane deliver --precheck_include_in_app_purchases before submitting. These dry runs catch missing screenshots, invalid ratings declarations, and content flags that would otherwise cost you a full re-review cycle.

Your listing conversion rate depends on screenshot quality and the first line of your description, so treat those assets with the same rigor you'd give a landing page A/B test.

Privacy disclosures and analytics pipelines

Both stores now enforce data safety declarations that go beyond linking to a privacy policy. Google Play's Data Safety form asks you to declare every data type collected, whether it's shared with third parties, and whether users can request deletion.

Apple's Privacy Nutrition Labels require the same granularity. If your app uses Firebase Analytics, you're collecting device identifiers and usage data. If you integrate Segment, every source you configure sends traits and events that qualify as personal data under both GDPR and CCPA.

Declare all of it. Reviewers cross-reference your binary's SDK signatures against your declarations, and inconsistencies trigger rejection or, worse, post-launch removal.

This connects directly to your analytics pipeline, because the SDKs you declare are the same ones feeding your dashboards. Before submission, confirm three things.

• Verify that Crashlytics receives symbolicated crash reports by uploading dSYM files for iOS (fastlane run upload_symbols_to_crashlytics) and enabling the Gradle plugin for Android's native symbols. Without symbolicated stacks, your crash-free rate metric exists but tells you nothing actionable.
• Define your expected event schema, at minimum app_open, onboarding_complete, first_purchase, and session_end, then validate that events fire correctly in both debug and release builds, because ProGuard and tree-shaking can strip event calls silently.
• If you use Segment as a routing layer to downstream tools, confirm that your write keys correspond to production sources rather than development ones.

Common thresholds for consumer apps put crash-free rate above 99.5% and Day-1 retention above 25%. You can't track either metric if your pipeline is misconfigured at launch, and the first cohort's baseline data is gone permanently once users arrive on a broken setup.

Staged rollouts and knowing when to pull back

A support channel isn't something you set up in week two. Both stores require a valid support URL and email in your listing metadata, and Google Play will flag apps that use a generic noreply@ address.

Your support channel is also the fastest signal source in the first 48 hours. Ratings and reviews lag by days, but direct support tickets surface crashes, payment failures, and onboarding confusion in near-real time.

Route tickets through a shared channel, whether that's Zendesk, Intercom, or a dedicated Slack pipeline, where engineering can triage alongside product. That feedback loop needs to be measured in hours.

That loop is what makes staged rollouts viable. On Google Play, you publish to internal testing first with up to 100 testers, then closed testing, then open testing, and finally a staged production rollout where you control the percentage, typically starting at 5% and scaling to 25% before full release.

If your crash-free rate drops below 99% in the 5% canary, you halt the rollout from the Play Console without pushing a new build. On the App Store, phased release distributes updates over seven days to auto-update users, and you can pause it from App Store Connect if Crashlytics shows a regression.

When we worked on ProWallet, a fintech payment app for the U.S. construction industry, the staged rollout caught a payment-flow edge case at 10% that would have affected thousands of transactions at full scale.

For CAA, Canada's largest automobile association with 7M+ members, the internal testing track let us validate real-time dispatch integrations before exposing the app to even a fraction of that user base.

With Tracer Golf in Toronto, which reached 13,200+ downloads, the tradeoff was different. A smaller audience meant we could move through tracks faster, and we still used the 5% canary to validate GPS accuracy across a wider range of Android devices.

At Somnio, these rollout decisions happen inside cross-functional squads where product, engineering, and QA share the same sprint cadence, so the call to halt or proceed doesn't wait for a meeting.

Artifact rollback means reverting to the previous APK/AAB or IPA in the store console. Feature-flag fallbacks, using tools like Firebase Remote Config, let you disable a broken feature without submitting a new binary at all.

Both mechanisms protect your Day-1 retention, because users who hit a crash on first open rarely return.

The complete pre-launch checklist

Each item below connects to a measurable outcome: conversion rate, Day-1 retention, crash-free sessions, or app marketing strategies that only work if your listing and pipeline are solid underneath them.

1. Verify your bundle ID matches across build.gradle, Info.plist, and your store developer accounts.
2. Confirm versionCode increments on Android and CFBundleVersion increments on iOS.
3. Run fastlane supply --validate_only and fastlane deliver --precheck_include_in_app_purchases.
4. Upload all required screenshots, descriptions, and localized metadata.
5. Complete Google Play's Data Safety form and Apple's Privacy Nutrition Labels, cross-referencing every SDK in your binary.
6. Upload dSYM files and enable native symbol uploads for Crashlytics.
7. Validate your event schema fires correctly in release builds across both platforms.
8. Set production write keys for Segment or any analytics routing layer.
9. Configure a real support email and URL in both store listings.
10. Set up your internal and closed testing tracks before promoting to production.
11. Plan a 5% staged rollout with a defined crash-free rate threshold for proceeding to 25% and then full release.
12. Prepare feature-flag kill switches for any new functionality.
13. Document your rollback procedure so any team member can execute it at 2 AM.

Why the Checklist Is the Cheap Part

Every item on this list connects to a number your board cares about: conversion rate, Day-1 retention, crash-free sessions, or time-to-resolution on critical bugs.

The whole list takes a few days of work spread across engineering, product, and legal. A single rejection over a mismatched privacy label costs about the same, and it costs it at the worst possible moment.

Skipping an item borrows time from your first users, who are also the cohort whose baseline data you can never collect again.

Frequently Asked Questions

How long does the app store review process typically take?

Apple's App Store review usually takes 24 to 48 hours for a standard submission, while Google Play reviews typically complete within a few hours to three days. Rejections due to metadata mismatches or privacy declaration issues reset that clock, which is why dry-run validation with fastlane before submission matters so much.

What happens if my analytics pipeline is misconfigured at launch?

You permanently lose baseline data for your first user cohort, which makes it impossible to establish accurate Day-1 retention or crash-free rate benchmarks. Those first-cohort numbers are the foundation for every product decision in the weeks that follow, and they cannot be reconstructed retroactively.

Can I skip the staged rollout if my app has already gone through internal testing?

Internal testing validates behavior within a controlled group, but a 5% production canary exposes your app to real device diversity, real network conditions, and real usage patterns that internal testers rarely replicate. The staged rollout is where edge cases like the ProWallet payment-flow bug surface before they affect your full user base.

What is the difference between artifact rollback and a feature-flag fallback?

Artifact rollback reverts the entire binary in the store console to a previously approved version, which affects all features at once and requires users to receive an update. A feature-flag fallback using a tool like Firebase Remote Config disables only the broken functionality remotely, without submitting a new binary, making it a faster and more surgical response to a regression.

Why do both stores require a real support email rather than a generic address?

Google Play explicitly flags noreply@ and similar addresses as policy violations, because the support contact is meant to be a functional channel for users with problems. Beyond compliance, a real support inbox is your earliest signal for crashes and onboarding failures in the first 48 hours, before ratings and reviews catch up.

Working With Somnio Software

At Somnio Software, we work closely with companies to design and build high-quality digital products using modern technologies and development best practices. If you're looking for a trusted partner to bring structure, expertise, and innovation to your next software project, we'd love to connect.

Contact us to learn how we can help turn your product vision into reality.