Blog Overview
What must be ready before the build, how to test on an old device and a slow network, what the store rejects, and four numbers to watch in week one.
Launching an app is not the moment it goes live in the store. It is the first day a real user opens it, signs up, pays, and hits an error nobody saw in testing. Most problems in the first week are not deep engineering bugs. They are untested details: an Arabic error message, a notification that never arrives, a missing privacy policy, or a store review that rejects the app description.
This is the launch checklist we use, arranged in four stages. It is not exhaustive for every app, but it covers the most common reasons a launch slips or the first week fails.
Stage one: before the build
Decisions at this stage protect the launch later. If deferred, they become expensive changes in the final week.
| Stage | What must be ready | Owner |
|---|---|---|
| Before build | Privacy policy, consent screen, and the list of data collected | Owner and legal |
| Before build | Apple developer account and Google Play account, with identity verification | Owner |
| Before build | Bundle names, icon, store screenshots, and Arabic and English descriptions | Marketing and design |
| During build | Separate production environment, secrets management, and backups | Engineering |
| During build | Event analytics, crash reporting, and server alerts | Engineering and product |
| During build | Support plan: who answers, on which channel, during which hours | Operations |
| Before release | Security review and a light penetration test of sensitive flows | Security |
| Before release | Closed beta with 20 to 50 real users | Product |
Stage two: testing
The test that matters is not “does the button work?” but “does the user complete the task?” Separate functional testing from experience testing. The first prevents crashes; the second prevents silent failure, where a user completes the steps and does not understand the outcome.
Test at minimum on an older iOS device, a mid-range Android device, a slow network, dark mode, and a large Arabic font. Those five reveal problems that never appear on the newest office device. Add a completely new user state: no data, no prior notifications, no history.
Create a new account on a clean device. Do not use a test account with data.
Complete the core flow in Arabic only. Do not switch to English halfway.
Cut the network mid-step. Does a clear message appear, or does the screen hang?
Deny a permission, then request it again. Can the user continue?
Send a notification with the app closed. Does it arrive, and does it open the right screen?
Test payment, then refund. Does the state match in the app and the dashboard?
Set the font to maximum size. Is the text readable and the buttons tappable?
Open the app after a week of no use. Is the session intact, or does it demand a login for no reason?
Stage three: the store
Before you open the store page, write the description as if it were a two-line ad. The user does not read five paragraphs. They see the icon, the first two screenshots, and the first sentence. If they do not understand in three seconds what they get, they will not download. This is not only marketing. It is the same principle as the app's first screen, except it happens before installation.
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
The store does not test your product, but it rejects what breaks policy. The most common rejection reasons: an app without enough functionality, a misleading description, requesting data you do not need, an incomplete privacy policy, and using a trademark without rights. Read the guidelines before the build, not after a rejection.
Treat the store page as a landing page. The icon, the first three screenshots, and the first two lines of the description are what the user judges before downloading. Write the description in Arabic and English, and lead with the first benefit rather than a feature list. Review Google Play's data safety section and Apple's privacy labels, because both are checked against what the app actually collects.
Stage four: the first week
The first-week plan is not “we will monitor.” It is named roles and named numbers. Who checks crashes in the morning? Who replies to reviews? What threshold triggers a rollback? Who owns the rollback decision? If the answers are not written, day one disappears into discussion.
Watch four numbers only in the first week: crash rate, sign-up completion, payment completion, and support tickets per hundred users. Those four reveal most problems before they become bad reviews. To see how we build this stage into the project, see mobile app engineering.
The final launch checklist
A published privacy policy that matches what the app actually collects, in Arabic and English.
Google Play data safety and the App Store privacy labels completed.
Store accounts active and identity verification finished a week before launch.
A separate production environment with its own keys and backups.
Crash reporting and analytics working and visible in one dashboard.
A published support line with a channel, hours, and escalation path.
A closed beta with 20 to 50 real users.
A written rollback plan: when we halt the release, who decides, and how users are told.
A full Arabic review of every message, error, and notification.
One launch owner who holds decisions on day one.
Frequently asked questions
How long does store approval take? Usually one to three days, longer after a rejection and resubmission. Plan a week of margin.
Do we need a penetration test before launch? Yes if the app handles payments or sensitive data. A light review is not enough.
Should we launch on both platforms together? No, unless the audience is split. Start with one and stabilise the experience.
Do we need a beta? Yes. Twenty real users reveal what an internal team cannot.
What is the most important first-week number? Core flow completion, not download count.
Sources
- Apple App Store Review Guidelines — functionality, privacy, and description rules.
- Google Play developer policies — data safety and release requirements.
- PDPL implementing regulation — consent, disclosure, and notification.
- Mobile app cost in Saudi Arabia — what the band covers and what comes after.
- Mobile app engineering — how we build and launch.
