A security scan and an app store review ask different questions. Here's why app store rejection happens to secure builds, and what enterprise mobile teams check before they submit.
Your build passed binary SAST. DAST ran clean on real devices. QA signed off, and the launch date went out to customers. Then the store console said no.
Nothing in the security report was wrong.
It was answering a different question. Your security scan asked whether the build could be exploited, while Apple and Google asked whether it met their submission rules.
That second question catches a lot of builds. In 2024, Apple rejected 1,931,400 of the 7,771,599 app submissions it reviewed, roughly one in four, according to its App Store Transparency Report.
A security scan asks whether a build can be exploited, while the store review asks whether it follows Apple's or Google's rules on privacy, permissions, declarations, billing, and performance.
As a result, a build can clear one bar and fail the other in the same week. Your security report and the store's rejection notice can both be accurate.
|
Security testing |
App store review |
|
|
Question it asks |
Can this build be exploited? |
Does this build follow the store's rules? |
|
Who runs it |
AppSec and DevSecOps teams |
Apple and Google reviewers |
|
When it happens |
Before release |
After submission |
|
What fails a build |
Exploitable vulnerabilities |
Policy, privacy, design, performance or legal issues |
|
What you get back |
Findings with severity and fixes |
Approval or a rejection notice |
That timing gap is where release dates slip. So before your next submission, run an app store readiness check on the build first.
Often enough to plan for.
In 2024, Apple reviewed 7,771,599 app submissions and rejected 1,931,400 of them, with performance issues leading by a wide margin (Apple, 2024 App Store Transparency Report).
|
Apple guideline category |
Submissions rejected in 2024 |
|
Performance |
1,235,471 |
|
Legal |
445,696 |
|
Design |
378,300 |
|
Business |
209,845 |
|
Safety |
116,105 |
|
Other |
23,659 |
One submission can be rejected under more than one guideline, so the categories add up to more than 1,931,400.
Google reports what it stopped rather than a rejection rate.
In 2025, it prevented over 1.75 million policy-violating apps from being published on Google Play and kept over 255,000 apps from getting excessive access to sensitive user data (Google, 2025 Play safety review). The two datasets measure different things, so they can't be compared directly.
AppSec owns vulnerabilities, QA owns function, engineering owns the build, and the release team owns submission, so store requirements often get checked for the first time in the store console.
The problem is not that teams ignore store rules. It is that few stages before submission are built to check them.
Only partly. Google's pre-review checks flag issues such as missing mandatory declarations and high crash rates, but they start only once a release is in Play Console, and Google notes that "passing all pre-review checks does not guarantee passing the formal app review process."
Every app, release, and regional variant adds one more place for a store issue to surface late. So the gap grows fastest for teams running many apps, frequent releases, or launch dates tied to partners and regulators.
App store readiness means a build meets the published review rules of the store it's headed to before a reviewer ever opens it. That covers declarations that match what the binary and its SDKs really do, permissions tied to a feature, billing that follows each store's rules, and a clean release configuration.
In other words, it's a check on the build you'll ship and what it declares, not just on its code. Here's where reviewers tend to look:
|
Area |
What reviewers check |
A common reason builds fail |
|
Performance and stability |
Whether the app works as described, without crashes or unfinished features |
Crashes on specific devices or OS versions |
|
Privacy and data declarations |
Whether declared data collection matches what the app and its SDKs collect |
A third-party SDK collects data the listing doesn't declare |
|
Permissions |
Whether each sensitive permission maps to a feature that needs it |
A permission requested "just in case" |
|
Billing |
Whether purchases of digital goods follow the store's billing rules |
Digital goods sold outside the required billing system |
|
Release configuration and declarations |
Whether required declarations and settings are complete |
Missing mandatory declarations at submission |
|
Third-party components |
Whether bundled SDKs and services follow current store policy |
An SDK that passed last quarter breaks a rule that changed this quarter |
So store readiness isn't a one-time checklist. Store policies change, and so do the SDKs inside your build.
A rejection rarely costs one fix. More often, it restarts a loop:
Apple's own numbers show that loop at scale. In 2024, 295,109 submissions were approved after an earlier rejection, according to the same Transparency Report.
Each one is a build that went back to its team, went through fixes and retests, and then waited its turn for a second review.
Security scans don't look for that.
Enterprise teams shipping business-critical apps treat store readiness as a release gate with an owner, not a last-minute console check. The store verdict sits next to the security verdict before anyone presses submit.
Beyond that, a few habits make the gate work:
The gate matters most where a missed date is expensive. Think of a bank releasing retail and business apps in several regions at once, or a travel app whose bookings depend on the next release going live on time.
|
For the full pre-release list, download the Mobile App Release Readiness Checklist. |
Appknox Store Release Readiness checks every build you upload against Apple App Store and Google Play submission requirements. It rates each app's Release Rejection Risk as High, Medium, or Low, then lists blockers and warnings with the evidence, the store policy, and the fix.
If you're an Appknox customer, you already have it on by default and at no added cost. If you're not a customer yet, you can run a free Store Readiness Scan on an Android build today.
|
Appknox customers |
Free Store Readiness Scan |
|
|
How to access it |
Upload a build in your Appknox dashboard |
Upload an APK or AAB on the scan page |
|
Cost |
Included at no added cost |
Free |
|
Store coverage |
Apple App Store and Google Play |
Google Play |
|
Deployment |
Cloud and on-premises |
Web upload |
|
What you get |
Release Rejection Risk rating, blockers, warnings, evidence, policy references and remediation guidance |
An on-screen verdict, a Store Readiness Snapshot by email, and an optional 15-minute remediation call with an Appknox specialist |
|
No credit card, no commitment. Just upload your APK or AAB and the scan does the rest, with no source code needed. Already an Appknox customer? Store Release Readiness runs automatically on your next build upload. |
Yes. A security scan checks whether a build can be exploited, while App Store review checks it against Apple's or Google's rules on privacy, permissions, billing, and performance. A build can pass one and fail the other.
Performance. In 2024, Apple rejected 1,235,471 submissions under its performance guidelines, more than any other category, according to its App Store Transparency Report.
No. Google states that passing all pre-review checks does not guarantee passing the formal app review process.
Yes. If an SDK collects data your privacy declarations don't mention, or breaks a store policy that has changed, the whole build can be rejected.
Before submission, on the same build you plan to ship. Checking at upload, beside your security results, leaves time to fix blockers before the release date is at risk.