LaunchLint Academy
The short answer
- React Native and Expo are not rejection categories. Risk appears at the boundaries between JavaScript, native configuration, backend services, store metadata, and the exact path a reviewer can access.
- The most common testable groups are incomplete submissions under Guideline 2.1, inaccurate metadata under 2.3, payment mistakes under 3.1, insufficient lasting value under 4.2, and privacy or account-deletion gaps under 5.1.
- Do more than patch the cited number. Reproduce the reviewer’s path in the submitted production build, fix the underlying cause, and reply with verifiable evidence instead of a broad assurance.
1. Why React Native is almost never the root cause
Apple reviews the delivered product, its metadata, and observable behavior. Whether the interface was built with SwiftUI, React Native, or Expo does not change those requirements. The framework matters where abstraction hides native details: a config plugin adds a permission, an SDK transmits data, dynamic configuration resolves different release values, or an over-the-air update no longer matches the submitted binary.
First assign the rejection to an evidence layer. A login crash belongs to the binary or backend. An unavailable purchase may involve product configuration or review access. A wrong privacy answer lives in the store console but may be caused by an SDK. Separating these layers prevents rushed changes in the wrong place.
| Layer | Typical evidence | First question |
|---|---|---|
| Repository and build | Plugins, permissions, SDKs, identifiers | Is the signal in the submitted artifact? |
| Running app | Crash, login, purchase, deletion, permission prompt | Can a fresh reviewer reproduce the flow? |
| Store context | Screenshots, privacy answers, notes, products | Do the declarations describe this build? |
2. Guideline 2.1: incomplete build or blocked review access
Guideline 2.1 covers more than crashes. Apple expects a final binary, complete metadata, functional URLs, and access to essential features. Otherwise stable apps fail because a demo account expired, a staging backend sleeps, login depends on a one-time code, or a feature flag is disabled for the review user.
Test on an unrelated device before resubmitting:
- First launch without a saved session
- Login with the exact review credentials
- Backend, uploads, and media reachable from an external network
- Core feature works without an internal invitation
- In-app purchases are visible and current
- Denying camera, location, or push does not dead-end
- Support and privacy URLs open publicly
3. Guideline 2.3: the store promise conflicts with the app
Apple explicitly treats descriptions, screenshots, previews, and privacy information as metadata that must reflect the core experience. A common mismatch appears when marketing captures come from a newer branch than the submitted binary or advertise a premium flow that the review account cannot reach.
Map every strong claim to a reproducible path. Statements such as anonymous, offline, no tracking, or AI-powered need special care because SDKs, network calls, or limited functionality may contradict them. Remove internal debug menus, placeholders, test pricing, and imagery from unrelated mobile platforms.
Metadata reconciliation:
- Every screenshot shows reachable UI
- Name and subtitle promise no missing capability
- Additional purchases are clearly disclosed
- What’s New names material changes
- Age rating matches content and user-generated content
- Privacy policy and store label describe the same release
4. Guideline 3.1: digital purchases, restore, and review products
The permitted payment route matters when digital features, content, or subscriptions are unlocked. A Stripe SDK or web checkout in a repository is not automatically a violation; the risk is using it to unlock digital in-app functionality or directing users to a prohibited external purchase path in a particular storefront. Regional exceptions and entitlements require specific analysis.
Correct StoreKit code can still fail under 2.1 when products were not submitted, are invisible, or cannot be tested. Exercise loading, cancellation, success, restore, an already active subscription, and reinstall. Explain in review notes when and how each product becomes visible.
- Check product status and agreements in App Store Connect
- Review account reaches the paywall without an internal switch
- Restore Purchases is visible and works
- Price and term are clear before confirmation
- No production secret is embedded in code or notes
- Document regional availability and non-obvious conditions
5. Guideline 4.2: insufficient lasting app value
Guideline 4.2 targets apps that mainly repackage a website, collect links or marketing material, or provide too little durable utility. This often affects thin WebView wrappers and template-generated apps. Adding a few native buttons is not the answer; reviewers evaluate the actual function and specific user value.
State the recurring job the app completes and show why the device experience matters. Offline use, camera or location workflows, notifications, device capture, and thoughtful mobile interaction can add value only when they genuinely work. Do not invent decorative or unfinished features for review.
6. Guideline 5.1: privacy, permissions, and account deletion
Privacy problems usually come from mismatches. The repository includes analytics, crash, or authentication SDKs that the policy omits; a permission prompt merely names the resource; or store answers claim no collection although data leaves the device. Third-party code remains the app provider’s responsibility.
If the app creates accounts, test the complete deletion path. Apple expects deletion to be initiated inside the app. Logging out or deactivating the profile is not enough. Explain required retention, handle active subscriptions deliberately, and test confirmation, re-authentication, and failure states.
Evidence for the fix:
- Specific purpose string for every sensitive permission
- SDK inventory with data type, purpose, and recipient
- Public policy covering retention and deletion
- In-app account-deletion path
- Store answers checked against actual transmission
- New binary created after native configuration changes
7. Turn the rejection into a verifiable resubmission
Read the exact guideline, test path, and attachments first. Reproduce that path with the rejected build before changing code. Then determine whether a new binary is required or whether a metadata-only issue can be corrected with the same build. Apple explicitly allows the same build to be resubmitted after a metadata fix.
A strong reply names the cause, the concrete change, and where it can be verified. For example: ‘We replaced the expired demo account. The export is now available under Account > Demo Projects without an invitation; verified in build 42.’ Avoid debating the framework or saying everything works without a path and build reference.
Resubmission log:
- Record guideline and reviewer steps
- Reproduce the issue in the rejected build
- Assign the cause to an evidence layer
- Document fix and regression test
- Name build number and navigation path
- Send a concise factual reply with optional attachment
- Appeal only when the policy interpretation remains substantively disputed
Frequently asked questions
Are React Native apps rejected more often?
Apple does not publish a reliable rejection rate by framework. React Native is not the reason; stability, native configuration, metadata, payments, privacy, and a fully reviewable flow are what matter.
Does every rejection require a new binary?
No. Some metadata issues can be corrected and resubmitted with the same build. Changes to code, SDKs, permissions, or native configuration require a new binary and a higher build number.
Can LaunchLint guarantee App Store approval?
No. Static analysis can find reproducible repository signals and policy questions, but it cannot fully evaluate a backend or a human review decision. It reduces risk and produces evidence-backed fix tasks.
How should I answer an unclear rejection?
Ask for the exact test path in App Store Connect, reproduce the stated condition, and reply with the build, navigation, and evidence. A formal appeal remains available when the policy interpretation is genuinely disputed.