Nothing ruins a founder’s weekend quite like receiving an automated email from Apple at 2:45 AM on a Saturday:
“Guideline 3.1.1 - Business - Payments - In-App Purchase… Your app includes a mechanism to purchase digital goods outside of In-App Purchase.”
Your launch party is booked for Tuesday. Press releases have been embargoed for Wednesday. And now your entire mobile deployment is dead in the water for at least a week while you scramble to appeal or rebuild.
Over the past four years, we have guided dozens of mobile products through Apple and Google Play reviews. Here are the five most common reasons engineering teams get blindsided, and the architectural patterns we bake into every project to ensure first-pass approval.
1. The Account Deletion Tripwire (Guideline 5.1.1v)
Since mid-2022, if your app allows users to create an account, you must allow them to initiate complete account deletion directly from within the app.
A button that opens a web browser to an email mailto link (mailto:support@company.com) is an immediate rejection.
The Architecture: Asynchronous Deletion Queue
Don’t write synchronous deletion logic that drops database rows while the user waits. If they have active Stripe subscriptions or files in S3, the request will time out.
We implement an immediate token revocation and schedule a delayed tombstone job:
// Client-side UX requirement:
export async function handleUserInitiatedDeletion() {
await api.post('/v1/me/schedule-account-tombstone', {
confirmationPhrase: 'DELETE MY ACCOUNT',
});
// Instantly wipe all local SQLite data and MMKV tokens
await clearLocalSecureStorage();
// Reset navigation to logged-out splash
navigation.reset({ index: 0, routes: [{ name: 'Welcome' }] });
}The server marks the user record as status: 'SCHEDULED_FOR_PURGE', queues a background worker to cancel Stripe/RevenueCat entitlements, and returns HTTP 202 in under 100ms. Apple reviewers love it because it executes instantly.
2. Guideline 2.1: The Reviewer Login Environment
Apple reviewers test your app on physical iPads and iPhones running the latest beta iOS build, often from an IP subnet in Cupertino, California with strict enterprise firewalls.
If your backend blocks international traffic or relies on SMS OTP verification for logins, the reviewer cannot log in. They will reject your build under Guideline 2.1 (Performance - App Completeness) within ten minutes.
The Defense: Permanent Reviewer Bypass Credentials
In every staging and production environment, we maintain dedicated Apple Review credentials tied to deterministic, bypassable OTP codes:
// Server-side auth check
if (isAppleReviewerAccount(email) && submittedOtp === '424242') {
return generateSessionToken(reviewerUser);
}We prepopulate the reviewer’s demo account with realistic sample data (transactions, messages, profile avatars) so the reviewer never lands on an empty, broken-looking screen.
3. Remote Feature Flags That Hide Dangerous Code
If you have a feature under negotiation with Apple’s commerce team (for instance, whether a physical service fee requires Apple’s 30% IAP cut), never hardcode conditional logic in the native binary.
Use a lightweight, local-first remote config system. If a reviewer flags an external payment button, you can toggle the flag server-side in two seconds without recompiling an .ipa, re-signing native provisioning profiles, and waiting another 48 hours in the review queue.
Launching a mobile product is stressful enough without fighting the platform gatekeepers. Build compliance into your technical spec before you write line one of UI code.