Fetching offerings errors are among the most common issues developers face. These typically occur when RevenueCat can't retrieve product information from the app stores.

Issue 1: "None of the products could be fetched" Error

Error Message

[RevenueCat] 🍎‼️ Error fetching offerings - The operation couldn't be completed.
(RevenueCat.OfferingsManager.Error error 1.)
There's a problem with your configuration. None of the products registered in the RevenueCat dashboard
could be fetched from App Store Connect (or the StoreKit Configuration file if one is being used).
More information: https://rev.cat/why-are-offerings-empty

Common Causes

1. No Products Configured: Products not set up in RevenueCat dashboard.
2. Product ID Mismatch: IDs in RevenueCat don't match store products.
3. Products Not Available in Current Storefront: Testing from unsupported region.
4. Bundle ID / Package Name Mismatch: App identifier doesn't match dashboard.
5. Products Not Approved (iOS): Products pending review in App Store Connect.
6. Service Account Issues (Android): Google Play credentials not configured.

Solution Steps

Step 1: Verify Products Exist in RevenueCat

1. Go to RevenueCat dashboard.
2. Navigate to Product Catalog → Products.
3. Verify you have products listed.
4. If empty, import products or create them manually.

Step 2: Verify Product IDs Match Store

For iOS:

1. Check product IDs in App Store Connect.
2. Compare with RevenueCat dashboard (Product Catalog → Products).
3. Ensure exact match (case-sensitive).

For Android:

1. Check product IDs in Google Play Console.
2. Compare with RevenueCat dashboard.
3. Ensure exact match (case-sensitive).

Step 3: Verify Products Are in an Offering

1. In RevenueCat dashboard, go to Product Catalog → Offerings.
2. Select your offering (usually "default").
3. Check that packages exist and contain products.
4. If no packages, click Edit and add packages with products.

Step 4: Check Platform-Specific Setup

For iOS:

• Verify bundle ID matches in RevenueCat (Apps & providers → App Store).
• Ensure products are approved or use StoreKit Configuration File.
• Check sandbox tester is signed in (if testing in sandbox).

For Android:

• Verify package name matches in RevenueCat (Apps & providers → Google Play).
• Ensure service account is configured and has permissions.
• Verify products are Active in Google Play Console.
• Ensure app is published to at least Internal Testing.

Issue 2: Empty Offerings

Symptoms

• offerings.all is empty.
• offerings.current is nil.
• No error message, but offerings object has no data.

Common Causes

1. No Packages in Offering: Offering exists but has no packages.
2. No Default Offering Set: No offering marked as default.
3. Products Not Attached to Packages: Packages exist but have no products.
4. Offering Identifier Mismatch: Code requests wrong offering identifier.

Solution Steps

Step 1: Verify Offering Has Packages

1. In RevenueCat dashboard, go to Product Catalog → Offerings.
2. Click on your offering (e.g., "default").
3. Verify the Packages section has at least one package.
4. If empty, click Edit and add packages.

Step 2: Verify Packages Have Products

1. For each package in your offering.
2. Verify it has products attached for your platform (iOS or Android).
3. At minimum, each package needs one product ID.

Step 3: Set Default Offering

1. In Product Catalog → Offerings.
2. Find your main offering.
3. Check if "Current" badge is displayed.
4. If not, click the offering → Make Current.

Step 4: Verify Code Uses Correct Identifier

iOS:

let offerings = try await Purchases.shared.offerings()

// Check if current offering exists
if let offering = offerings.current {
    print("Offering: \(offering.identifier)")
    print("Packages: \(offering.availablePackages.count)")
} else {
    print("No current offering set")
}

Android:

val offerings = Purchases.sharedInstance.awaitOfferings()

// Check if current offering exists
offerings.current?.let { offering ->
    Log.d("RC", "Offering: ${offering.identifier}")
    Log.d("RC", "Packages: ${offering.availablePackages.size}")
} ?: Log.d("RC", "No current offering set")

Issue 3: Offering Configuration Warnings

Error Message

warning: The offerings 'default' have configuration issues that may prevent users from
seeing product options or making purchases.
Product Issues:
• Package 'monthly' references product 'premium_monthly' which is not available

Common Causes

1. Missing Product for Platform: Package has iOS product but no Android product (or vice versa).
2. Incorrect Product Association: Product attached to package doesn't exist in store.
3. Platform Filter Issue: Product exists but is filtered out for current platform.

Solution Steps

Step 1: Check Package Configuration

1. In RevenueCat dashboard, go to your offering.
2. For each package, verify it has products for both iOS and Android (if you support both platforms).
3. If you only support one platform, ensure products exist for that platform.

Step 2: Verify Product Exists in Store

1. Copy the problematic product ID from the warning.
2. Check if it exists in App Store Connect or Google Play Console.
3. If it doesn't exist, either:
   • Create the product in the store, OR
   • Remove/update the product reference in RevenueCat.

Issue 4: Network and API Errors

Error Message

Error: Unable to fetch offerings
NetworkError: The Internet connection appears to be offline
Error: Request timed out

Common Causes

1. No Network Connection: Device has no internet access.
2. Firewall/VPN Blocking: Corporate network or VPN blocks RevenueCat servers.
3. Invalid API Key: Wrong API key configured.
4. Server Issues: Rare RevenueCat service disruption.

Solution Steps

Step 1: Verify Network Connection

1. Test internet connectivity on device/simulator.
2. Try opening a website in browser.
3. Check Wi-Fi/cellular data is enabled.

Step 2: Check API Key

// Verify you're using the correct API key for your platform
// iOS: Should start with "appl_"
// Android: Should start with "goog_"

Purchases.configure(withAPIKey: "appl_xxxxxxxxxxx")

Step 3: Test Without VPN/Proxy

1. Temporarily disable VPN or proxy.
2. Test if offerings fetch successfully.
3. If successful, configure VPN/firewall to allow RevenueCat domains.

Step 4: Implement Retry Logic

func fetchOfferingsWithRetry(maxRetries: Int = 3) async throws -> Offerings {
    var lastError: Error?

    for attempt in 1...maxRetries {
        do {
            return try await Purchases.shared.offerings()
        } catch {
            lastError = error
            if attempt < maxRetries {
                // Wait before retrying (exponential backoff)
                try await Task.sleep(nanoseconds: UInt64(pow(2.0, Double(attempt))) * 1_000_000_000)
            }
        }
    }

    throw lastError ?? NSError(domain: "Offerings", code: -1)
}

Issue 5: Offerings Work in SampleCat But Not in My App

Symptom

You can retrieve offerings and products using RevenueCat's SampleCat app (or the REST API), but your own app returns empty offerings or fails to fetch products, even though the bundle ID is the same.

Why This Happens

If SampleCat works with the same bundle ID, it proves your RevenueCat dashboard configuration and store products are correct. The issue is in how your app initializes or communicates with the SDK. The bundle ID, API key, and store must form a complete chain:

Store (App Store / Google Play)
        ↕  (product IDs must match)
RevenueCat Project (bundle ID configured here)
        ↕  (API key + bundle ID must match)
Your App (bundle ID in Xcode/Gradle + API key in code)

All three layers must be aligned. If any link is broken in your app but not in SampleCat, your app will fail while SampleCat succeeds.

Solution Steps

Step 1: Verify your API key

This is the most common cause. Double-check that your Purchases.configure() call uses the exact same public API key that SampleCat uses.

// iOS: Key must start with "appl_"
Purchases.configure(withAPIKey: "appl_YOUR_PUBLIC_KEY")

// Android: Key must start with "goog_"
Purchases.configure(this, "goog_YOUR_PUBLIC_KEY")

Step 2: Check SDK initialization timing

Purchases.configure() must be called as early as possible in your app lifecycle, before any offerings fetch. If it is called too late or conditionally, the SDK may not be ready when you request offerings.

// iOS: Configure in AppDelegate or App init
func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    Purchases.logLevel = .debug
    Purchases.configure(withAPIKey: "appl_YOUR_KEY")
    return true
}

// Android: Configure in Application.onCreate()
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        Purchases.logLevel = LogLevel.DEBUG
        Purchases.configure(PurchasesConfiguration.Builder(this, "goog_YOUR_KEY").build())
    }
}

Step 3: Check for errors in the callback

Always inspect the error parameter when fetching offerings. A silent failure here is the most common reason for "it just doesn't work."

Purchases.shared.getOfferings { offerings, error in
    if let error = error {
        print("❌ Error fetching offerings: \(error.localizedDescription)")
        return
    }
    guard let current = offerings?.current else {
        print("⚠️ No current offering found")
        return
    }
    print("✅ Current offering: \(current.identifier)")
    print("   Packages: \(current.availablePackages.map { $0.identifier })")
}

Step 4: Verify StoreKit Configuration (iOS Simulator only)

When running on the iOS Simulator, your Xcode project needs a StoreKit Configuration file. SampleCat includes one by default, but your project may not.

1. In Xcode, go to Product → Scheme → Edit Scheme → Run → Options.
2. Check the StoreKit Configuration dropdown.
3. If it says "None", either create a StoreKit Configuration file with matching product IDs, or test on a physical device with a sandbox account instead.

Step 5: Enable debug logs and compare

Add Purchases.logLevel = .debug (iOS) or Purchases.logLevel = LogLevel.DEBUG (Android) before configure(). Run both SampleCat and your app, then compare the debug output. Look for differences in:

• The API key being used.
• The app user ID.
• The products returned from the store.
• Any error messages during initialization.

Issue 6: Products Have "READY_TO_SUBMIT" Status

Symptoms

You see two log messages in sequence. First, a warning that the SDK is configured correctly but products have issues:

WARN: ⚠️ RevenueCat SDK is configured correctly, but contains some issues you might want to address

Warnings:
  • Your products are configured in RevenueCat but aren't approved in App Store Connect yet.
    This prevents users from making purchases in production.

Product Issues:
  ⚠️ monthly (monthly): This product's status (READY_TO_SUBMIT) requires you to take action
    in App Store Connect before using it in production purchases.
  ⚠️ yearly (yearly): This product's status (READY_TO_SUBMIT) requires you to take action
    in App Store Connect before using it in production purchases.

Offering Issues:
  ⚠️ default
    ⚠️ $rc_monthly (monthly): status (READY_TO_SUBMIT)
    ⚠️ $rc_annual (yearly): status (READY_TO_SUBMIT)

Then, an error that none of the products could be fetched:

ERROR: 😿‼️ There is an issue with your configuration. Check the underlying error for more details.
More information: https://rev.cat/sdk-troubleshooting
There's a problem with your configuration. None of the products registered in the RevenueCat
dashboard could be fetched from App Store Connect (or the StoreKit Configuration file if one
is being used).
More information: https://rev.cat/why-are-offerings-empty

Why This Happens

The READY_TO_SUBMIT status means your products exist in App Store Connect but have never been submitted for review. Apple requires in-app purchase products to be submitted alongside an app version. Until they are reviewed and approved, the App Store will not serve them to your app in production.

The key insight here is in the WARN message itself: "RevenueCat SDK is configured correctly." This confirms your RevenueCat dashboard setup, API keys, and bundle ID are all fine. The problem is purely on the App Store Connect side.

Understanding Product Statuses

Solution Steps

Step 1: Complete your product metadata in App Store Connect

For each product with READY_TO_SUBMIT status, ensure it has all required metadata:

1. Go to App Store Connect → Your App → Subscriptions (or In-App Purchases).
2. Click on each product and verify it has:
   • A Reference Name and Product ID.
   • At least one Subscription Price or price tier configured.
   • A Localization with display name and description.
   • A Review Screenshot (a screenshot showing the product in your app).

Step 2: Submit your products with an app version

In-app purchase products must be submitted with a new app version:

1. In App Store Connect, go to your app → create a new version (or use a pending version).
2. Scroll to the In-App Purchases and Subscriptions section.
3. Click the + button and select your products.
4. Submit the version for review.

"Do I Need to Submit for Review to Test Purchases?"

There are two completely separate things:

Step 3: Test without waiting for approval

You can test purchases right now with "Ready to Submit" products. Choose one of these approaches:

Option A: StoreKit Configuration File (Recommended, fastest)

This is the fastest way to test. It works offline with no Apple dependencies:

1. In Xcode, go to File → New → File → StoreKit Configuration File.
2. Add each product with the exact same Product ID as in App Store Connect.
3. Set the product type, price, and duration to match your App Store Connect configuration.
4. Go to Product → Scheme → Edit Scheme → Run → Options.
5. Under StoreKit Configuration, select your new .storekit file.
6. Build and run. Products will load instantly.

Option B: Sandbox Testing (on a physical device)

This tests against Apple's sandbox servers, which is closer to the real production environment:

1. Create a sandbox tester in App Store Connect → Users and Access → Sandbox Testers.
2. On your test device, go to Settings → App Store → Sandbox Account and sign in with the sandbox credentials.
3. Make sure your Xcode scheme has StoreKit Configuration set to "None" (so it uses the real sandbox, not the local file).
4. Run the app on the device. "Ready to Submit" products are available in the sandbox.

Option C: RevenueCat Test Store

Use RevenueCat's Test Store for fast, deterministic testing without needing Apple's infrastructure at all. No sandbox accounts, no StoreKit files needed.

Issue 7: StoreKit Can't Resolve Products Despite Correct RevenueCat Config (iOS)

Symptom

Your RevenueCat dashboard and API show offerings configured correctly with the right product identifiers. Products exist in App Store Connect. However, when the app calls Purchases.shared.offerings(), the availablePackages array comes back empty. No error is thrown, but no products are displayed.

let offerings = try await Purchases.shared.offerings()
// offerings.current exists, BUT:
print(offerings.current?.availablePackages.count) // 0

The key diagnostic clue: if you query the RevenueCat REST API directly, the offerings and products are returned correctly. The gap is between "RevenueCat server knows the products" and "StoreKit can't resolve them on the device."

Why This Happens

When getOfferings() is called, the RevenueCat SDK performs two steps:

1. Fetches the offering configuration from RevenueCat's servers (offering identifiers, package identifiers, product IDs). This step works because your dashboard is configured correctly.
2. Resolves product identifiers with StoreKit by calling Apple's Product.products(for:) (StoreKit 2) or SKProductsRequest (StoreKit 1). If StoreKit cannot resolve the product IDs, the packages are filtered out and availablePackages is empty.

Apple's StoreKit requires a binary activation step: the first time you use specific product IDs in an app, Apple needs to process at least one app binary (uploaded to App Store Connect) to link those product identifiers to your app. Until this processing is complete, StoreKit will not resolve the products, even though they exist in App Store Connect.

When This Typically Occurs

• Brand new products: You just created in-app purchase products in App Store Connect for the first time.
• First-ever app submission: The app has never had a binary uploaded to App Store Connect before.
• New product IDs added: You added new products to an existing app but haven't submitted a build since creating them.

How to Distinguish This from Other Issues

If all rows match this pattern, the issue is StoreKit product activation.

Solution Steps

Step 1: Upload a binary to App Store Connect

Submit a build through Xcode or CI/CD that references the in-app purchase product IDs:

1. Archive your app in Xcode (Product → Archive).
2. Upload to App Store Connect via Distribute App → App Store Connect.
3. Alternatively, use xcodebuild or Fastlane to upload.
4. Wait for Apple to process the build (typically 15-30 minutes, can take longer).

You do not need to submit the build for review. Simply uploading it to App Store Connect (making it available in TestFlight) is enough to trigger the activation.

Step 2: Wait for Apple's processing

After the build is uploaded:

• Apple processes the binary and links the product identifiers to your app.
• This can take anywhere from 15 minutes to a few hours.
• You can check the build's processing status in App Store Connect under TestFlight.
• Once the build shows "Ready to Test" in TestFlight, the products should start resolving.

Step 3: Test again

After the build is processed:

1. Install the build from TestFlight on your device, or run from Xcode on a device with a sandbox account.
2. Call Purchases.shared.offerings() again.
3. availablePackages should now be populated.

Alternative: Use a StoreKit Configuration File for immediate testing

If you need to test right away without waiting for binary activation:

1. In Xcode, create a StoreKit Configuration File (File → New → File → StoreKit Configuration File).
2. Add products with the exact same product IDs as in App Store Connect.
3. Go to Product → Scheme → Edit Scheme → Run → Options.
4. Select your StoreKit Configuration file.
5. Products will resolve immediately using the local configuration.

Issue 8: "No Subscriptions Available" on iOS (Coming from Android)

Symptom

You've completed all the RevenueCat configuration (products, offerings, packages, API key), but when testing on iOS the app shows an error like:

Error: no subscriptions available. Try again later.

This is particularly common for developers who have experience with Android/Google Play and are setting up iOS for the first time. The RevenueCat side is configured correctly, but something on the Apple side is preventing products from loading.

Most Common Cause: Paid Applications Agreement

The #1 cause for first-time iOS developers is the Paid Applications Agreement not being signed or incomplete. Unlike Google Play, Apple requires you to complete business and banking information before any in-app purchase products will work, even in the sandbox.

To fix this:

1. Go to App Store Connect.
2. Navigate to Business (formerly "Agreements, Tax, and Banking").
3. Check for any banners or warnings at the top of the page.
4. Complete these sections:
   • Paid Applications Agreement: Must show Active status. If it says "Pending" or "New," click to accept the terms.
   • Banking Information: Add your bank account details.
   • Tax Forms: Complete the required tax forms (W-9 for US, W-8BEN for non-US developers).
5. Wait up to 24-48 hours for Apple to verify your information (banking verification can take time).

Other Causes (iOS-Specific Gotchas for Android Developers)

If the Paid Applications Agreement is already active, work through this checklist of iOS-specific requirements that don't have Android equivalents:

Common Issues Quick Reference

Debugging Checklist for Offerings Issues

• ☐ Products exist in RevenueCat dashboard.
• ☐ Product IDs match exactly with store (case-sensitive).
• ☐ Offering has packages with products attached.
• ☐ Default offering is set.
• ☐ Bundle ID / Package name matches.
• ☐ API key is correct for platform (appl_ or goog_).
• ☐ Network connection is available.
• ☐ Products are approved (iOS) or Active (Android), not "Ready to Submit."
• ☐ Debug logging is enabled.
• ☐ Testing with valid credentials (sandbox or Test Store).