Custom mobile app development done but can't be listed? What review requirements usually block it?

App development completion does not equal being able to be listed. Based on project delivery habits in 2026, most review rejections are not program performance issues but compliance issues: missing privacy policies, excessive permission requests, missing APP filing, or non-compliance with in-app purchase rules. Checking item by item against the platform's official specifications and the delivery acceptance checklist before submission can intercept most common rejections. "Listing" here refers to release on app stores for public users, not enterprise internal distribution.

Why isn't a finished app enough for listing? These four things are what actually block it

The development phase usually focuses on whether functions work and the UI matches the design, while listing review focuses on compliance and experience. Based on our experience delivering enterprise projects, many clients get stuck because "development is done, but review time wasn't scheduled", causing the launch date to be delayed repeatedly. Review is not a submission action but an independent acceptance phase that requires materials to be prepared in advance.

Combined with common practices in 2026, the high-frequency causes for review rejection are concentrated in four categories. Listed below from highest to lowest occurrence probability, each with key judgment points and counterexamples.

• Privacy policy and user agreement: App stores require a clear, accessible privacy policy that states what personal information is collected, the purpose, and whether third-party SDKs are integrated. Counterexample: The privacy policy only says "Our company does not collect any information", but the code calls a tracking SDK.
• Permission requests and scenario descriptions: Permissions such as camera, location, and contacts must be used in actual functions, and their purpose must be explained in the configuration. Counterexample: A notes app requests call log permission, and the review is directly rejected.
• APP filing: For listing in China, the MIIT APP filing must be completed; it is still a hard requirement in 2026. Filing requires domain, server, business license and other information, with a typical cycle of 1-2 weeks. Counterexample: A small team thinks it can be supplemented later, but the store requires the app to be removed.
• In-app purchases and content compliance: Apple has clear commission requirements for virtual payments, and Android stores require additional qualifications for apps containing finance, medical, second-hand trading, and other content. Counterexample: The app offers membership unlock but uses Alipay direct connection instead of Apple IAP, so after rejection the code must be changed.

Four-step self-check method before listing: check in this order before submitting

Why this order? Because the cost of a review rejection is time—solve the one-veto items first, then polish the details. We have seen many teams do UI adaptation first, but the filing hadn't been approved, so they waited two weeks for nothing. The four steps are arranged by the dependency: threshold → information → functionality → compatibility.

On-site delivery has a common constraint: the client has a limited budget and a cycle of only 8 weeks. At the end of development, they discover the filing wasn't scheduled, so the launch is delayed by 2 weeks and an emergency filing fee is added. That's why the first step in the four-step method is to check qualifications.

1. Verify qualifications and filing: Confirm whether the business license, domain filing, and APP filing are completed, and whether the software copyright is in place (required by some Android stores). What counts as qualified: before submission, the "filed" status can be seen in the corresponding store backend.
2. Check privacy and permissions: Verify whether the privacy policy text matches the actual behavior of the code, and check the Android permission and iOS permission lists item by item. Qualification standard: permission request dialogs can correspond to specific feature pages and have explanatory text.
3. Test payment and content compliance: Run through the complete flow, check whether virtual products use Apple IAP, and check whether the user agreement includes account cancellation, minor protection, and other clauses. Qualification standard: no policy violation pop-ups appear in the test environment.
4. Perform multi-device compatibility: Cover mainstream devices and OS versions from the past three years based on the experience range, and at least verify first launch, registration, payment, crash, and background recovery. Qualification standard: no crashes on common models, no serious layout distortion on older OS versions.

What are the requirement differences among domestic Android markets, the App Store, and overseas channels?

Different channels may produce completely different review results for the same app. For example, domestic Android markets generally require APP filing, but overseas Google Play does not; Apple is strict about privacy labels and virtual payments, while domestic Android more commonly requires software copyright. When doing custom development, you cannot write code to just one set of standards.

• Apple App Store: Review cycle is usually 1-3 business days; privacy labels must be configured, IDFA usage must be explained, virtual products must go through IAP, and external payment cannot be guided.
• Domestic Android markets (Huawei, Xiaomi, OPPO, vivo, Tencent MyApp, etc.): Review cycle is about 1-5 business days; APP filing is generally required, some require software copyright, and privacy dialogs must comply with the four-ministry standards.
• Overseas Google Play: Requires a developer account; review has high requirements for target API level and data safety form; ads must declare SDKs. Review cycle is usually 1-3 days.

Reminder: If your app is planned for multiple markets, it is recommended to list each market's review points at the prototype stage rather than supplementing them after development. Paid compatibility testing can be considered, but based on experience, doing your own self-check first saves more money than blind testing.

Applicable scenarios and boundaries: which businesses don't need to be forced onto stores

Cases suitable for listing usually meet the following conditions:

• For mass users and requiring public download;
• Rely on the trust endorsement of app stores, such as enterprise qualifications and rating systems;
• Need to complete version updates and distribution through the store.

These businesses should schedule listing work into the development plan and reserve 2-4 weeks for review and modification.

Cases that are not suitable or do not need to be listed:

• Used by internal employees; can use enterprise signing or MDM;
• Closed deployment in vertical industries, such as hospital intranet or construction site inspection;
• Demo or small-scale internal testing; can use TestFlight or Android internal testing platforms.

These scenarios do not need to bear the compliance costs of public listing. Listing is not the end; delivery completeness and matching business goals are.

FAQ

How long does app listing review usually take?

Apple review usually takes 1-3 business days, domestic Android markets 1-5 business days, but if there is a rejection and supplementary materials are required, based on experience it will add another 3-10 days. Estimate 2-4 weeks when scheduling.

Can an app be listed without a software copyright?

Some domestic Android markets require software copyright; Apple does not. You can use electronic copyright or expedited software copyright, but there is a time cost. It is recommended to clarify in the contract who is responsible for the application.

Does the privacy policy have to be written by a lawyer?

Not necessarily. Small projects can modify mainstream templates, but they must cover the list of collected information, SDK directory, user rights, and cancellation method. Lawyer review is more reliable, with a fee of a few hundred to several thousand yuan, depending on budget.

What materials are needed for APP filing?

Business license, legal representative ID, domain and server information, as well as app name and icon. Filing is completed through designated platforms/channels or submitted through the MIIT system, with a typical cycle of 1-2 weeks.

Will modifying and resubmitting after rejection affect rankings?

The impact is very small. Apple and Android markets usually only look at the current review status and do not lower weight because of a rejection. However, repeated rejections will delay launch, so it is recommended to fix everything at once.

If you are in the custom development or delivery phase, it is recommended to put the listing review checklist into the contract's acceptance items, clarifying the "responsibility and cost attribution for modifications after submission is rejected due to compliance issues". Based on 2026 experience, reserve a 2-4 week review buffer for public listing projects; internal projects do not need to follow this. When unsure, first do minimal internal testing and validation before deciding whether to launch on public channels.