Why do Apple or Google reject an app?

Ask someone who has never seen the product to open the candidate build on a clean device. Can they register or use the test account? Does verification arrive? Is there enough sample content to complete a purchase, booking, or upload? The app may work for your team because their phones have been logged in for months, while a reviewer sees an empty screen or unsupported location. Prepare valid test data, each user role where roles differ, and concise instructions for any step outside the app.

Check reviewer access at a different time and from another network before submission. If a feature requires manual approval by an administrator, make the approved test path available or explain it through the official review channel. Do not share a real customer’s record or a broadly privileged administrative password just to accelerate testing.

Review app name, description, screenshots, video, and claims. A screenshot of a report that has not shipped creates a misleading expectation even if the review happens to pass. Read every sentence as a promise to users: does the feature work in the submitted version, and are subscription or payment conditions understandable? Use images of the real experience in the relevant language. Marketing should not update the listing independently of the build engineering tested.

Open support and privacy links on a phone without signing in. Make sure email or help forms work. If the product is available in several languages or markets, inspect permission explanations and error messages in the published languages, not just the attractive first screen.

List every permission requested on iOS and Android. Which feature stops working without it, when is it requested, and what happens when the user declines? The purpose should be clear at the moment the feature is used, while unrelated parts remain usable where possible. Review analytics, advertising, and notification libraries as well; they may handle data product owners overlook when preparing store disclosures. Compare actual behaviour with privacy statements through suitable technical and legal review.

If the app handles accounts, payment, or location, test storage, staff access, and account requests against current platform rules. Logs and support tools can contain identifiers or sensitive images too. A correct policy document is insufficient if the deployed app sends data the team has not mapped.

Walk through the main task with a weak connection, declined permission, expired session, failed payment, and slow server. Show useful messages and avoid losing user work without warning. Examine crashes in the latest test build; do not submit simply because one problem disappeared on a developer’s phone. Test the devices and operating-system versions your listing claims to support.

Check buttons opening external pages, deep links from email or adverts, and notifications leading to internal screens. An app can work from its home icon and fail when a real user arrives through a campaign link. A short release checklist catches many of these errors before upload.

Link the specific review message to the submitted build and affected scenario. Do not resend the same package with a different description before understanding the issue. Record reproduction steps, make the fix, retest with a fresh account and device, then respond clearly through the platform’s channel. If the decision appears inconsistent with the app’s behaviour, use the available clarification or appeal route rather than making random changes.

Before final submission, ask someone outside the development team to complete the core journey without guidance. Watch where they stop: is account creation blocked, is a permission unexplained, or does poor connectivity produce an empty screen? Record the issue, screenshot, and exact steps to reproduce it, then repair and retest. Provide reviewers with working test credentials and sample data that expose no real customer information. This exercise reveals product defects as well as review risks and reduces last-minute release cycles.

Keep a release file with version, available features, test accounts, links, data disclosures, permission review, and passed and failed scenarios. Revisit Apple’s guidelines and Google Play policy at submission because rules evolve. Thorough preparation reduces avoidable review problems but cannot guarantee approval; the aim is a real, stable user experience that matches the store listing.