App Store rejected your custom-built app: fix the code or the submission materials first?

Bottom line first: When a custom-developed app is rejected by App Store review, it is usually not because the code fails to run, but because the submission materials and review rules are not aligned. In 2026 deliveries, the high-frequency blockers cluster in five areas: account deletion entry, login method, virtual goods payment path, permissions and privacy copy, and metadata and screenshots. Self-check against the rules first, then decide whether to touch the code — it usually saves time compared with submitting repeatedly; the typical range from resubmission to a result is 1 to 3 days, and longer if additional explanation is requested.

Why a rejection is often not a technical problem

When a team gets rejected for the first time, the instinct is to go back and check crash logs. But the words that appear more often in review feedback tend to be rule items like account deletion, privacy, and metadata. Review has two layers: automated pre-checks and human review. Automated pre-checks scan permission declarations, privacy manifests, and the SDKs inside the binary; human review looks at whether the account system, payment path, and description copy are self-consistent. Neither layer focuses on whether the business logic is correct — they focus on whether users can exit on their own, delete their own account, and understand how they are charged.

Technical functionality working is only a necessary condition for passing review, not a sufficient one. Treating review as an acceptance checklist with explicit line items is closer to reality than treating it as a code exam. When you need a basis, check the current items in the App Store Review Guidelines and the submission prompts in App Store Connect one by one — that saves more time than changing things based on impressions.

On delivery sites, a common situation: the client's release date is only two weeks away, the privacy policy is not finalized, and the screenshots are still design mockups. The approach is to fill in the account deletion entry and permission purpose copy first, then produce screenshots consistently; the cost is an extra round of design changes, but it is lighter than being rejected after submission and delaying the whole schedule. The typical range for this kind of documentation rework is 1 to 3 business days, while payment path changes often take weeks.

Five types of submission materials to check before you submit

These five are interrelated: login method affects how account deletion is done, payment rules affect how the description is written, and permissions appear in both privacy copy and screenshots. Self-check in the order below to reduce back-and-forth rework.

1. Account system: If users can register, they must be able to delete their account, and the deletion entry must be findable in the app — not just a customer service email. The typical range for adding this is 3 to 10 business days.
2. Login method: If you offer third-party login, evaluate against the current guidelines whether an equivalent other registration or login path is needed; do not copy an old project.
3. Payment path: First determine whether you are selling virtual content or physical goods or offline services. The rules differ, and going the wrong way is one of the more common reasons for rejection.
4. Privacy and permissions: Each permission's purpose description must state the specific use; do not write empty phrases like 'to improve experience.' The privacy policy link must open.
5. Metadata and screenshots: Screenshots must not contain unfinished placeholder text, test account prompts, or watermarks from other platforms.

What counts as a passing self-check: find someone who was not involved in development, hand them a real device, and have them go from registration to deletion without asking you questions. If they can complete it, it passes; where they get stuck is usually where review will get stuck.

Why account deletion and login methods are so often where things go wrong

The root cause of account deletion rejections is often not that the feature was not built, but that it was built where a reviewer cannot find it. A common case is that the deletion entry is buried three levels deep under Settings - About - More, or requires contacting customer service for manual handling. Human review will not search for you; if it cannot be found, it is treated as missing.

Login method is easily influenced by old habits. In 2026, a common approach is: if the app supports third-party account login, also evaluate whether an equivalent registration or login path should be offered, rather than leaving only a third-party entry. Specific clauses get updated, so check the current review guidelines at delivery time — do not directly reuse a plan from two years ago.

• Passing line: Registration, login, and deletion form a closed loop inside the app, not dependent on external customer service.
• Counterexample: The delete button only says 'Request deletion'; tapping it goes to a form, and after filling it out you wait for an email.
• Cost: This kind of problem is not a big rework, but each review communication round typically takes 1 to 3 days, and near a release date it can easily delay the whole schedule.

Virtual goods vs. physical services: how do you draw the payment boundary?

Payment is where review disputes concentrate. The core distinction is whether the user is paying for digital content inside the app or physical goods or offline services outside the app. The former usually must use in-app purchase; the latter generally can use third-party payment. If you judge the direction wrong, the fix involves the order flow and refund logic — not just changing a button.

• Option A: In-app purchase — suitable for memberships, unlocked features, virtual items, ad removal, and other digital content; the platform takes a share per the rules, and integration and reconciliation usually need 1 to 3 weeks.
• Option B: Third-party payment — suitable for physical goods, in-store services, and offline fulfillment orders; merchant qualifications need to be prepared in advance, and at review you must be able to explain clearly that fulfillment happens outside the app.
• Mixed scenario: If one app sells both virtual and physical items, separate the entries and the explanations — do not make the reviewer struggle to tell what is being bought on one page.

If you are not sure which category applies, a common 2026 approach is to first check the guideline items defining digital content and physical goods, then decide the technical approach — that is more cost-effective than developing first and remediating later.

What other less obvious pitfalls are there?

Some details developers think are fine, but the review rules have explicit requirements. It is worth a quick pass before submission.

• Test environment in screenshots: Screenshots containing 'test,' 'demo,' or 'contact admin' can easily be treated as an unfinished product.
• Privacy policy is an unmodified template: If the company name, collected fields, and SDK list do not match, you may be asked for additional explanation.
• Permission request copy too vague: The purpose descriptions for camera, location, and contacts must match the actual features.
• Absolute language in the description: Both the submission description and screenshot copy can be blocked for exaggerated claims.

To self-check whether it passes, use a simple standard: can someone unfamiliar with the project, looking only at the in-app copy and screenshots, explain what this app collects, how to exit, how to delete, and how to pay? If not, there is still rejection risk.

Applicable scenarios and boundaries

This self-check method applies to custom development projects preparing to submit to the App Store, especially those that implement their own account system, payment, and privacy permissions, and to teams publishing for the first time. It addresses what to check before submission; it does not address whether the features meet business expectations.

Cases where it should not be directly copied also need to be stated clearly: apps distributed only internally via MDM or enterprise signing do not go through public App Store review, and the rules differ; apps submitted only to third-party Android markets face requirements that are not fully consistent across markets; pure H5 or mini-programs do not involve this process. Boundary sentence: If the app is not distributed for public download, or has no account or payment at all, then most of the checks in this article can be skipped, and effort should go to the rules of the relevant channel.

Frequently asked questions

After rejection, how long does resubmission usually take?

As an experience range, resubmission to result is typically 1 to 3 days, and longer around holidays or when additional explanation is required. So if you can complete the self-check in one go, do not split it into multiple trial rounds.

Can account deletion be handled by customer service on the user's behalf?

Usually not enough. Review prefers a self-service deletion path inside the app; customer-service deletion may in some cases require adding a self-service entry.

Will using third-party payment for virtual goods definitely be rejected?

In most cases you will be required to switch to in-app purchase, unless you can clearly prove the purchase is for physical goods or offline services fulfilled outside the app. The basis for judgment is the current review guidelines.

Are the pitfalls the same for Android release and iOS review?

Not completely. Account deletion and privacy permissions are common items, but payment rules, metadata, and channel asset requirements differ by platform. It is better to produce separate checklists per channel.

If I hire an outsourcing team to submit, do I still need to manage review myself?

It is advisable to keep the submission account and final confirmation authority yourself. As a delivery habit, the vendor prepares the submission materials and the client confirms them, which reduces back-and-forth caused by non-compliant descriptions.

When preparing to submit, first go through the five items — account deletion, login method, payment type, permission copy, and screenshot metadata — then check the current review guidelines for gaps. If the project is stuck because your own team lacks release experience, Xiyue Company can organize the submission checklist in parallel during the delivery phase. If the app is not distributed to public app stores, just check against the relevant channel's rules first.