What Actually Gets Your App Rejected, and What It Costs in Time

The published genre of app-rejection content is about dramatic policy fights. The reality Apple describes is duller and more useful: "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more."

Apple names the specific offenders: crashes and bugs, broken links, placeholder content, incomplete information, privacy policy issues, and unclear data access requests. And it is explicit about links: "All links in your app must be functional. A link to user support with up-to-date contact information and a link to your privacy policy is required for all apps."

That is a checklist, not a philosophy. Most rejected submissions are rejected because something was unfinished, and most of those are avoidable in the hour before submitting.

This one is worth knowing before you commission an app, because it determines whose account it ships from, and it surprises people.

Apple's guideline 4.2.6 reads: "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients."

Read strictly, an agency that builds apps for clients and submits them from its own developer account is in scope. Apple's stated remedies are that the client submits under their own account, or that the provider ships one aggregated app rather than many similar ones.

The practical consequence is that your app should be submitted from your own Apple Developer account, with your agency added to it, rather than from theirs. That also means you own the listing, the reviews and the relationship with Apple, which is where they should sit anyway. Any agency that wants to keep your app on its own account is arranging things for its convenience and against your interest, and now has a guideline problem as well.

This is the single most common request that fails review, and it fails on a guideline written specifically for it.

Guideline 4.2: "Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or app-like, it doesn't belong on the App Store." And 4.2.2: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Google Play has its own version, rejecting apps "that only have limited functionality and content", naming "apps that are static without app-specific functionalities, for example, text only or PDF file apps".

The answer is not a better wrapper. It is to identify what the app does that the website cannot: offline access, notifications, camera, location, a genuinely different interaction. If there is no such thing, a good mobile website is the honest product and it costs less.

Account deletion is the one that catches teams who build for Apple first. Apple requires that "if your app supports account creation, you must also offer account deletion within the app". Google goes further and requires the deletion path to exist both in-app and on a web resource, and states that "account freezing is not a valid substitute".

Build Apple's version only and you will pass Apple and fail Play. It is cheaper to build the stricter requirement once.

The second is public identity, and it matters more for individual developers than most realise. Apple's EU trader requirements state that "even if you don't distribute apps in the EU, you'll still need to declare a trader status", and an individual must publish an address, phone number and email on the product page. Google similarly displays verified developer information. If you are an individual developer, your home address can end up publicly listed. An organisation account with a D-U-N-S number avoids that, which is our reading of the rules rather than something either store spells out.

Less than the anxiety suggests, usually. Most rejections name a specific guideline and a specific problem, you fix it and resubmit, and the second review is typically fast because Apple reviews 90 percent of submissions in under 24 hours.

Apple also grants a useful concession on bug-fix updates: "If you're submitting a bug fix update for your app and we find additional issues during review, you have the option to resolve the additional issues with your next submission, as long as there are no legal or safety concerns." So a bug fix does not get held hostage to an unrelated finding.

If you believe the rejection is wrong, there is an appeal to the App Review Board, for cases where "we misunderstood your app's concept and functionality, or that you were treated unfairly". Apple asks for specific reasons and permits "only one appeal per submission". Expedited review exists for genuine emergencies, with a warning that abusing it affects future requests.

What nobody publishes is how long any of that takes. Apple gives no appeal or expedite turnaround, and Google gives no median review time at all. Anyone quoting you a number for a rejection-to-relaunch cycle is quoting experience, not policy, and should say so.