The Review Process Is a Black Box
Apple's App Store review process is famously opaque. You submit your app, wait 24-72 hours, and either get approved or receive a vague rejection notice citing a guideline number. Over the last three years, we've submitted about 85 app versions to the App Store and been rejected 23 times. That's a 27% rejection rate, which is actually better than the industry average. Here are the technical issues that caused those rejections and how we prevent them now.
Guideline 4.3: Spam (The "Your App Is a Website" Rejection)
This is the most common rejection we see for React Native and Flutter apps. If your app is essentially a WebView wrapper around a website, Apple will reject it under Guideline 4.3. We had a client who wanted to "just wrap their web app in a native shell" for the App Store. Apple rejected it twice with the feedback that the app didn't provide sufficient native functionality to justify its presence on the App Store.
The fix: ensure your app uses native components for core interactions. Use native navigation (not web-based routing), native form elements, native notifications, and at least one meaningful native feature (camera, biometrics, offline access, widgets). For the client above, we added biometric authentication, push notifications, and an offline mode. Approved on the third submission.
Guideline 2.1: Performance (Crashes and Bugs)
Apple tests your app on the oldest supported iOS version. If your minimum deployment target is iOS 15 but you only tested on iOS 17, you're going to have a bad time. We got burned by this when a client's app used an API that was only available in iOS 16+ but the deployment target was set to iOS 15. The app crashed on launch during Apple's review.
Our prevention: we maintain a device lab with older devices — an iPhone 8 running iOS 15, an iPhone SE running iOS 16, and an iPhone 11 running iOS 17. Every submission is tested on all three before going to review. We also run the app in the iOS Simulator with slow animation mode enabled, which surfaces timing-related crashes that don't appear at normal speed.
Guideline 5.1.1: Data Collection and Privacy
Apple is increasingly strict about privacy labels and data collection transparency. If your app uses analytics, tracks location, or accesses the clipboard, and your privacy label doesn't declare it, you'll get rejected. We had an app rejected because a third-party SDK (ironically, a crash reporting tool) was collecting device identifiers that we hadn't declared in our privacy label.
Now, before every submission, we audit all third-party SDKs for data collection using the privacy manifests that Apple requires since Spring 2024. We also test with the "Record App Activity" feature in iOS Settings, which shows exactly what data your app accesses. It's tedious but it's caught issues that would have caused rejections.
Guideline 3.1.1: In-App Purchases (The Money Problem)
If your app sells digital content or subscriptions, you must use Apple's In-App Purchase system and give Apple their 30% cut. There is no negotiating this. We had a client who wanted to sell online courses through their app using Razorpay. Apple rejected it immediately. The options: use IAP (and lose 30%), or only sell through the web and remove all purchase flows from the app.
The exception: physical goods and services can use external payment processors. Uber uses Stripe, not IAP, because rides are a physical service. We've successfully argued that certain real-world service bookings (appointments, consultations) are physical services and can use Razorpay. But digital content — courses, premium features, virtual goods — must go through IAP. Plan your monetization strategy before writing code, not after.
Our Submission Checklist
After too many rejections, we created a 32-point pre-submission checklist that we run through for every App Store submission. It covers the technical issues above plus: proper entitlements configuration, background mode justification, camera/microphone permission strings that clearly explain why they're needed, proper deep link handling, and screenshots that accurately represent current app functionality. Since implementing this checklist 14 months ago, our rejection rate dropped from 27% to 8%.