US | Launch | 2026-08-22

App Store Review Rejections and How to Avoid Them

Most small business apps get rejected for the same handful of reasons, and almost all of them are fixable before you ever hit submit.

A dog grooming shop submitted their booking app on a Thursday afternoon. Apple's review came back in eleven hours with Guideline 2.1 — Performance — App Completeness. The reason: the reviewer created an account, was asked to verify by email, and the verification email never arrived because the sending domain wasn't configured for the demo environment. The app worked fine on real devices. It just didn't work for the one person who mattered on the one afternoon that mattered.

That is the shape of most rejections. Not architectural failures, not policy fights — small operational gaps that a reviewer with a fresh device and no context runs straight into. If you understand what the reviewer is actually doing for those eight to fifteen minutes, you can head off nearly all of it.

What the reviewer is actually doing

App Review is a human on a device, working from a queue, with a checklist and a time budget. They install your build, open it cold, and try to reach the thing your listing promises. They read your App Store Connect metadata. They check your privacy labels against what the app appears to do. They look for anything that says "Lorem ipsum" or "Coming soon." If there's a paywall, they poke it. If there's an account, they try to delete it.

They do not have your context. They don't know your business. They don't know the account creation flow requires an approval step from your office manager. Everything they need has to be in the app, or in the review notes field, or it doesn't exist.

Google Play works differently — more automated scanning, more policy checks against your Data Safety form and declared permissions, less manual poking. But the same categories of problem trip both.

Incomplete information: the rejection that isn't your app's fault

Guideline 2.1 covers apps the reviewer couldn't fully evaluate. In practice, for small business apps, that means one of four things:

• No demo account. If your app has a login, App Store Connect has a Sign-In Information section. Fill it in. Use a real, working account with realistic data in it — not an empty shell. Keep it alive through the whole review; deactivating it mid-review reads as a broken app.
• The demo account can't reach the good part. A restaurant app where the demo account has no order history looks like an app with no features. Seed it.
• Hardware or location gating. If your app pairs with a Bluetooth scale, a card reader, or only shows content within a geofence, the reviewer in Cupertino cannot test it. Provide a video demo link in the review notes and, ideally, a debug bypass.
• Verification codes the reviewer can't receive. SMS OTP is the classic one. Either whitelist a fixed code for the demo number, or use an account that skips verification.

The review notes field is not decoration. Three sentences explaining "this app is for X business, the demo account has sample bookings under the Upcoming tab, the barcode feature needs physical inventory tags so here's a 40-second video" prevents a five-day round trip.

Sign-in required to see anything

Guideline 5.1.1(v) says apps may not require users to register or enable an account unless the account is directly tied to core functionality. Apple has applied this more aggressively over the last few years, and it catches a specific pattern that small business apps fall into constantly: the app opens on a login wall, and everything — menu, services, hours, portfolio, class schedule — sits behind it.

Ask yourself which parts of your app genuinely need to know who the user is. A salon's service list and pricing does not. Booking an appointment does. A gym's class timetable does not. Reserving a spot does. The fix is almost always a browsing mode: the app opens straight into content, and the sign-in prompt appears at the moment the user tries to do something that requires an identity.

This is also just a better product. Conversion on apps that show value before asking for credentials is meaningfully higher, and you avoid the rejection at the same time.

A related trap: if you offer any third-party sign-in (Google, Facebook), Apple requires an equivalent privacy-preserving option, which in practice means Sign in with Apple. Email-and-password only? No requirement. Add a Google button and you've triggered it.

Account deletion is now mandatory, and it's checked

Since mid-2022, any app that lets a user create an account must let them initiate deletion of that account from inside the app. Not "email support." Not "visit our website." In-app, and it must delete the account, not just deactivate it. Google Play added its own version in 2024, requiring both an in-app path and a publicly reachable web URL for deletion requests, declared in Play Console.

Reviewers look for this. It's a fast, binary check and it's a common rejection for apps built by teams who launched a web product first and never had the requirement.

What passes:

• A clearly reachable option in Settings or Account — not buried three levels into a help screen.
• A confirmation step is fine. A dark pattern that makes deletion functionally impossible is not.
• You may keep data you're legally required to retain (transaction records for tax purposes, for example) — say so plainly in the confirmation copy.
• If deletion is queued rather than instant, tell the user the timeframe.

Privacy labels that don't match behavior

Apple's Privacy Nutrition Labels and Google's Data Safety section are self-declared, which makes it tempting to fill them in optimistically. Both platforms run automated static and network analysis against what you declared.

The mismatches that catch small business apps are rarely deliberate. They come from SDKs. An analytics library collects device identifiers. A crash reporter sends coarse location. An ad SDK does considerably more than you assumed. The app developer declared "no data collected" honestly, because they weren't collecting anything themselves — the dependency was.

Before submitting, list every third-party SDK in the build and read its documented data collection. Both Apple and Google publish guidance; most major SDKs now publish a privacy manifest or a data-safety declaration you can copy from. Apple also requires privacy manifest files and signatures for a specified list of commonly-used SDKs, and builds missing them get flagged at upload.

Placeholder content and payments in the wrong lane

Two more that come up constantly.

Placeholder anything. A support URL pointing at a parked domain. A privacy policy link returning 404. Screenshots showing a feature the build doesn't have. "Terms of Service" text that still says [Company Name]. A "Coming soon" tab. Reviewers tap the URLs in your metadata. Make sure the privacy policy is live, on your domain, and actually describes your app.

Payments. This is the one with real money attached. The rule is about what you're selling, not how you built it:

A booking app that charges for a haircut uses Stripe. The same app charging $9/month to unlock advanced scheduling for the shop owner is selling digital access, and on iOS that needs StoreKit. Getting this wrong is a 3.1.1 rejection and a rebuild of your payment flow, so decide it before development starts, not after.

Realistic timelines

Apple publishes that a majority of submissions are reviewed within 24 hours, and in ordinary weeks that holds — first submissions often come back in 12 to 36 hours. Plan for longer around the September iOS release window and the December holiday shutdown, when Apple typically pauses review for roughly a week.

Google Play is slower for a first-time developer account than most people expect. New personal developer accounts face additional identity verification and, for personal accounts created after November 2023, a closed-testing requirement of 12 testers for 14 continuous days before production access. Updates to an established app usually clear in a day or two.

Budget two weeks of calendar time between "the build is done" and "it's live," assuming one rejection. Most first submissions get one. The teams that get through clean are not the ones with better code — they're the ones who filled in the review notes, seeded the demo account, and tapped their own metadata links before hitting submit.