What does a mobile app need before and after launch?
Most of a successful launch is engineering, not promotion. Before the first release an app has to clear each store's testing and privacy requirements, and it has to be able to measure itself. After release, the first month is spent fixing what real devices reveal and asking happy users for a rating at the right moment.
- Before submission: a beta on TestFlight and a Google Play closed test, the App Store privacy details and the Play Data safety form completed, and a demo account ready for the reviewer
- Built into the app: crash reporting, a short list of analytics events tied to the one action that matters, deep links, and a way to tell users an update is required
- After launch: watch crashes and drop-off daily, ship small fixes quickly, and use the system review prompt rather than a custom "rate us" button
What changed since this was first written
This post began in 2022 as a list of app marketing tips: pick keywords, study competitors, ask review sites to write about you, then buy ads. We do not sell marketing or advertising, and most of those tips assume an app that already works, measures itself and is allowed into both stores.
This version covers that part instead: what has to be built and set up before launch day, and what to watch in the first month afterwards. It is written for the person commissioning an app, so they know what to expect from whoever builds it. If that is still undecided, start with how to choose a mobile app development company.
What Apple and Google require before you can launch
Both stores have rules that decide your launch date as much as the code does. The ones that most often surprise a first-time app owner are below, checked against Apple's and Google's own documentation on 1 November 2026.
| Requirement | Apple App Store | Google Play |
|---|---|---|
| Beta testing | Betas and demos do not belong on the App Store; the App Review Guidelines send them to TestFlight | Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access |
| Privacy disclosure | App privacy details entered in App Store Connect, including the practices of third-party code built into the app | The Data safety form, required for every published app, including apps on testing tracks and apps that collect no data at all |
| Accounts | An app that lets people create an account must also let them delete it from inside the app | Not covered in the pages checked for this article; confirm in Google Play's policy centre before designing sign-up |
| Review readiness | Test on a real device, include demo account details if there is a login, and keep the back end switched on during review | Answer the closed-test questions when applying for production access |
| Asking for ratings | The system prompt is shown at most three times per app in any 365-day period | A time-bound quota limits how often the in-app review dialog appears, so it should never sit behind a button |
The Google Play closed test is the line most often missed in a plan. Fourteen days with twelve real testers cannot be compressed, so it belongs in the schedule from the start, alongside the stages in how long an AI app takes to build.
What to build into the app before the first release
These are small pieces of work during the build and expensive ones afterwards, because adding them later means another release through both stores. Ask for each by name in the brief.
- Crash reporting. A tool such as Firebase Crashlytics or Sentry, set up so a crash arrives with the device, the operating system version and the screen it happened on.
- A short list of analytics events. Sign-up started, sign-up finished, and the one action the app exists for, such as a booking or an order. Five well-named events beat fifty nobody reads.
- Deep links. Links that open a specific screen in the app, so an email, a text message or a web page can send someone straight to the right place.
- A required-update path. A way to tell users on an old version that they must update, for the day an old version stops working with your back end.
- Permissions asked in context. Notification and location requests shown when the feature needs them, with a sentence explaining why, not as a wall of prompts on first launch.
- A web page for the app. One page on your own site that explains what the app does and links to both stores, because plenty of people will search for it before they open a store.
Whether these are built once or twice depends partly on the route you choose, which cross-platform against native apps compares.
The store listing is part of the product
The name, icon, screenshots and description are what a person sees before they install, and the screenshots in particular should show the real app doing the one job it is for. These are product decisions as much as marketing ones, and they need the finished screens, which is why they so often get rushed in launch week.
The privacy answers also appear on the listing, so they have to match what the app really does. Every analytics or crash tool you add is third-party code the disclosure has to account for, which is one more reason to keep that list short.
What to watch in the first month after launch
The first weeks show how the app behaves on devices and networks nobody tested on. Each signal below points to a specific kind of fix.
| Signal | Where it comes from | What it usually means | Typical response |
|---|---|---|---|
| Crashes on one device or OS version | Crash reporting | A code path nobody tested on that hardware | A small fix release, prioritised by how many users it hits |
| Installs but no sign-ups | Analytics events | Onboarding asks for too much too early | Shorten sign-up, or let people look around first |
| Sign-ups but no core action | Analytics events | The main task is hard to find or fails silently | Watch real sessions, then simplify the path |
| One-star reviews describing a bug | Store reviews | A real defect that crash reports may not catch | Reply, fix, and say in the release notes that it is fixed |
| Support messages repeating one question | Email, chat, in-app help | Something the app does not explain | Change the screen, not just the help text |
Ask for ratings only after someone has succeeded at the main task, never on first launch, and use the system prompt on each platform. Google's own guidance warns against putting the review flow behind a button, because a user who has hit the quota taps it and nothing happens.
Where AI fits around a launch
AI is most useful after launch, where the volume of feedback outgrows the time anyone has to read it. Grouping store reviews and support messages by theme, drafting replies for a person to approve, and summarising each week's crash clusters are all jobs for AI automation connected to the app's data.
If the app itself has AI features, launch adds one more check: how those features behave with real users' inputs rather than test data. What AI-first app development means in practice covers how that is planned from the start.
Sign-ups and enquiries taken in the app also need somewhere to go. Routing them into your CRM setup and management, with follow-up handled by workflow automation, is what turns installs into customers.
What to agree with your developer before launch
- Who owns the Apple and Google developer accounts, and who has access to each
- Who completes the privacy details and the Data safety form, and from what list of tools
- Which analytics events will exist on day one, and who reads them
- Who watches crash reports in the first month, and how fast a fix reaches the stores
- Who replies to store reviews, and in whose name
We build apps through our AI app development service, and work is quoted per project. Our answers to common buyer questions cover who owns what we build and what we need from you to start.
Common questions
How long before launch should I start testing a mobile app?
Plan for at least two weeks of outside testing before release. A Google Play personal developer account created after 13 November 2023 must run a closed test with at least 12 testers for 14 days before it can apply for production access, so that test sets the minimum.
Do I need a privacy policy if my app collects no data?
On Google Play, yes. Google requires the Data safety form for every published app, including apps that collect no user data, and the form must link to a privacy policy that says so.
Can I add a button that asks users to rate the app?
Use the system review prompt instead of a custom button. Apple shows its prompt at most three times per app in a year, and Google limits its in-app review dialog with a quota, so a button would sometimes do nothing when tapped.
What should an app track from day one?
Crashes, plus a handful of analytics events: sign-up started, sign-up finished, and the main action the app exists for. Those are enough to show where people give up in the first month.
Does Satvik Infotech market or advertise apps?
No. We build mobile and web applications and the automation around them, including crash monitoring, analytics events and the CRM follow-up behind sign-ups. We do not run app marketing or advertising campaigns.