RevenueCat reports this state with a configuration warning: products registered in its dashboard could not be fetched from the App Store. Read that warning before changing anything; it identifies a product-resolution failure rather than an App Review decision.
Reproduce the blank paywall in the submitted build, then trace the warning through RevenueCat, App Store Connect, and release configuration. RevenueCat coordinates product data on top of Apple’s records; it does not create or submit those records.
The workflow below was checked against App Review Guidelines and RevenueCat: Troubleshooting Empty Products/Offerings on 4 August 2026. The first source controls the rule or workflow; the second supports the article-specific implementation boundary.
The short version
- Read the SDK’s own configuration warning before touching App Store Connect.
- Reproduce the empty state in the exact TestFlight build, not a simulator or a dev build.
- Confirm the public SDK key, not a placeholder or the wrong project’s key, ships in the release configuration.
- Match the app’s bundle identifier to the RevenueCat project entry character for character.
- Confirm each product is imported into RevenueCat and attached to the Offering the app actually requests.
Return to the iOS subscription and in-app purchase review guide after products load to verify the rest of the paid flow. Here, keep the scope deliberately smaller: prove whether the empty response begins in Apple’s product record, RevenueCat’s mapping, or the submitted build.
Start with the SDK’s own warning
Enable RevenueCat debug logging in a safe test build. Its troubleshooting documentation says an empty Offering can produce a warning that dashboard products could not be fetched from the store. Use the identifiers named by that warning to find which StoreKit lookup failed.
Understand what RevenueCat controls, and what it does not
RevenueCat documents three layers: products, packages that group them, and Offerings requested by the paywall. Its SDK receives your configured identifiers, then asks the device’s store to resolve them. App Store Connect still owns the product record, price, and review state; RevenueCat owns the import, package, and Offering mapping. No RevenueCat setting can create a missing Apple product.
Separate the two failure classes
Test each side independently instead of editing both at once.
In App Store Connect, confirm every required product has complete metadata, review information, pricing, and attachment to the reviewed version. In RevenueCat, confirm the product is imported, belongs to a package, and that package belongs to the Offering your code requests.
Then compare the iOS bundle identifier across Xcode, App Store Connect, and RevenueCat. In a multi-app RevenueCat project, selecting another platform’s app entry can produce the same empty-Offering warning even when every dashboard field looks complete.
Inspect release-only configuration
Expo, EAS, Xcode schemes, CI, and other build systems can use different variables for debug and release. Confirm the key present at runtime in the release build is RevenueCat’s public SDK key for the correct app, not a secret key, a placeholder, or a key copied from a staging project. Check that a local StoreKit configuration file was not the only reason products appeared to load during development; that file never talks to RevenueCat or the real App Store Connect item at all. Any correction baked into the binary needs a new build.
Design a paywall that survives an empty response
A store request can fail even when configuration is correct. Check for an empty Offering explicitly in code, replace the indefinite spinner with a concise unavailable message and a retry action, and keep legal links and a route out of the paywall available. This does not make missing products acceptable, but it prevents a transient fetch problem from looking like a frozen app.
Run the first checks in order
Work through these checks without changing two layers at once. A clean sequence makes the next decision defensible:
- Read the exact warning text in RevenueCat’s debug logs.
- Reproduce the failure in the exact TestFlight or distribution build.
- Confirm each product’s status and version attachment in App Store Connect.
- Confirm the product is imported, packaged, and attached to the requested Offering in the RevenueCat dashboard.
- Match the bundle identifier across Xcode, App Store Connect, and the RevenueCat app entry.
- Confirm the public SDK key present in the release configuration belongs to the correct RevenueCat app.
When a check fails, stop and record it. Fixing App Store Connect, the binary, and RevenueCat’s dashboard simultaneously destroys the evidence that tells you which change mattered.
Choose the next action
| What you find | Next action | New build? |
|---|---|---|
| A product sits in Missing Metadata or isn’t attached to the version under review | Complete the item in App Store Connect and confirm it’s in the draft | Usually no |
| A product is imported into RevenueCat but not attached to a package, or the package isn’t on the current Offering | Fix the mapping in RevenueCat’s dashboard | No |
| The release build ships the wrong SDK key, the wrong bundle identifier, or only a local StoreKit configuration file | Correct the app and release configuration, then archive and upload a new build | Yes |
| Both sides check out but the reviewer never reached the paywall | Rewrite Review Notes with a literal, reproducible path | Usually no |
| Apple’s message conflicts with a passing test on the same build | Ask for precise clarification, citing build and product identifiers | No, until a defect is identified |
Do not appeal a reproducible defect. Do not upload a replacement binary when the only issue is a dashboard mapping you can still edit. The warning text, the dashboard state, and your controlled test should choose the branch.
Failure patterns to look for
- The SDK warning was never read; App Store Connect and the binary got changed at the same time instead.
- A product exists in App Store Connect but was never imported into RevenueCat, or was imported and never attached to a package.
- A package is attached to an Offering the paywall code doesn’t actually request.
- The bundle identifier in RevenueCat’s app entry belongs to a different platform or app inside the same project.
- A local StoreKit configuration file made prices appear during development while the real App Store Connect product was still incomplete.
- The UI treats an empty Offering response as an endless loading state instead of a visible, retryable message.
The six patterns above are trace points, not a ranking of likely causes. RevenueCat’s current troubleshooting page controls claims about its SDK and dashboard; Apple’s documentation controls the product record and review requirements beneath it.
Put the right identifiers in App Review Notes
Give the reviewer a path they can follow without interpreting your product or your dashboard. Include the exact app version, build number, App Store Connect product identifiers, the Offering and package identifiers your paywall requests, any demo credentials, and the result expected after purchase or restore.
Keep the note factual. Say what you tested and where the control appears. Do not promise the environment will behave identically for every account, and do not imply that a recording replaces a submitted flow that actually returns products.
A useful structure is:
- Build, App Store Connect product identifiers, and RevenueCat Offering and package identifiers.
- Entry path from launch.
- Account or state required.
- Purchase or restore action.
- Visible result after the transaction.
What not to change blindly
Avoid recreating App Store Connect products, rotating the RevenueCat SDK key, or deleting and rebuilding the RevenueCat app entry before you know which object failed. Each of those changes can create new identifiers and new mapping work while leaving the original cause untouched.
Also avoid copying an App Store Connect path, or a RevenueCat dashboard screenshot, from an undated tutorial. Both interfaces move. Use the official pages linked in this article, then describe the labels you actually see in your own account and dashboard.
Verification note: Rule-sensitive claims in this article were checked against the linked Apple and RevenueCat documentation on 4 August 2026. Both can change labels, warning text, and workflow, so recheck the sources before publication or a later resubmission.
FAQ about RevenueCat products not loading App Review
Does an empty Offering always mean a RevenueCat problem?
No. RevenueCat can only import and package a product that already exists as a review-ready record in App Store Connect. An empty Offering is frequently an App Store Connect item that never finished setup, not a RevenueCat misconfiguration.
Can I trust a sandbox purchase that succeeded once?
No. It proves the Offering resolved and a purchase completed in the environment and build you tested. App Review also evaluates product rules, disclosures, access, metadata, and whether the item shipped in the submitted version at all.
Should I delete and recreate the RevenueCat app entry?
Only after the dashboard mapping, the bundle identifier, and the App Store Connect product status have all been checked and none explain the failure. Deleting an app entry changes identifiers you may already reference elsewhere and adds mapping work that a smaller fix would have avoided.
What evidence should I send to App Review?
Identify the app version, build number, App Store Connect product identifiers, the RevenueCat Offering and package requested, the exact test path, and the visible result. A short recording can support the explanation, but the submitted flow still needs to return products on its own.
Conclusion
Read the SDK’s own warning before you touch anything, then trace it through RevenueCat’s dashboard, App Store Connect, and your release configuration in that order. RevenueCat coordinates product data on top of Apple’s record; it does not decide whether that record exists.
Take the smallest action supported by the warning text and a test of the exact build. Keep the evidence with your reply so the next review starts from what actually failed, not another guess.
Sources and references
- App Review Guidelines: accessed 4 August 2026.
- RevenueCat: Troubleshooting Empty Products/Offerings: accessed 4 August 2026.
- Overview of testing in sandbox: accessed 4 August 2026.