When a Superwall paywall shows blank prices or missing products, the cause is almost always in StoreKit setup: product IDs, App Store Connect agreements, or a StoreKit configuration file. Fix it in order.
The symptom is a paywall that renders but shows no prices, empty product buttons, placeholder text where amounts should be, or a paywall that fails to display because it has no products to show. This is distinct from a paywall not presenting at all; here the paywall logic works, but the products it needs cannot be loaded from StoreKit. Because Superwall pulls price, currency, and trial details live from StoreKit at runtime rather than storing static prices, anything that prevents StoreKit from returning your products results in a blank or broken paywall. That is actually good news for diagnosis, because it narrows the cause to the StoreKit and App Store Connect layer that Superwall depends on but does not control. Confirm first that this is really a product-loading problem by checking whether the paywall frame appears while the prices are missing, and by testing on a real device with a sandbox account, since simulator behavior around StoreKit can differ. Once you are sure StoreKit is failing to return products, the fixes follow a predictable order of likelihood, starting with the identifiers themselves. Framing the problem this way is important because it keeps you from chasing Superwall configuration when the real fault is almost always in Apple's product setup, which is where nearly every blank-paywall investigation eventually lands.
The single most common cause is a mismatch between the product identifiers registered in Superwall and those created in App Store Connect. StoreKit only returns products for identifiers it recognizes, and it silently omits any it does not, so a single wrong character produces a blank slot with no obvious error. Open your App Store Connect in-app purchases and copy each product identifier exactly, then compare it to the identifiers you registered in Superwall and referenced on the paywall. Watch for capitalization differences, reversed domain segments, an extra or missing suffix, or a copy-paste that grabbed trailing whitespace. Confirm the bundle identifier of the app you are running matches the app the products belong to, because products are scoped to their app and will not load for a different bundle ID. If you have multiple environments or a staging bundle ID, make sure you are testing against the environment whose products you configured. This check is quick and resolves a large fraction of blank-paywall cases, so do it thoroughly before assuming something more complex is wrong. Only once every identifier matches character for character across App Store Connect, Superwall, and any local test config should you look elsewhere. Because StoreKit fails silently on unrecognized identifiers rather than raising an error you can see, this class of bug hides in plain sight, and the discipline of a literal character-by-character comparison beats eyeballing every time.
Even with correct identifiers, StoreKit will not return products if your account's Paid Applications agreement is not active. In App Store Connect, check the agreements, tax, and banking section and confirm the Paid Applications agreement is in effect with all required tax and banking information completed; if it is pending or expired, in-app purchase products will not load in production. Next, check the state of each product. New in-app purchase products must be fully configured and in a submittable or approved state before StoreKit reliably returns them, and a product still missing metadata, a price, or a required screenshot may not load. Newly created products can also take time to propagate through Apple's systems before they become available, so a product created minutes ago might simply not be ready yet. Verify each product has a price set for the storefronts you are testing, since a product with no price in a given region can appear absent there. These account-level and product-level conditions are outside Superwall entirely, but because Superwall depends on StoreKit, they directly cause the blank paywall, and they are the second thing to rule out after identifiers. The Paid Applications agreement in particular is easy to overlook because it can lapse when banking or tax details expire, silently disabling every in-app product across your whole account until someone renews it.
If you are testing locally in Xcode, a StoreKit configuration file can override where products come from, and a stale or mismatched one is a frequent cause of confusion. When a StoreKit configuration file is selected in your scheme, Xcode serves products from that file rather than from App Store Connect, so if its product identifiers do not match the ones your paywall references, products will appear blank even though App Store Connect is configured correctly. Open your scheme's run options and check whether a StoreKit configuration file is set. If it is, confirm its product identifiers, types, and prices match what Superwall expects, or remove it from the scheme to test against real sandbox products instead. Conversely, if you intend to test offline with local products, ensure the configuration file is selected and complete. Be deliberate about which mode you are in, because a common trap is debugging a blank paywall against App Store Connect while an old local StoreKit file is quietly intercepting the product requests, or vice versa. Knowing exactly where StoreKit is sourcing products removes a whole category of misleading symptoms and lets you trust what the paywall shows. A local StoreKit configuration file is excellent for fast iteration precisely because it does not require App Store Connect to be complete, but that same independence is what makes it so easy to forget it is active when you later try to test against real products.
Product loading behaves differently across environments, so test in the right one. On a real device, sign in with a dedicated sandbox Apple ID configured in App Store Connect's sandbox testers, not your everyday Apple ID, and use it only for the sandbox purchase environment. The simulator can be unreliable for StoreKit interactions, so a real device with a sandbox account is the most trustworthy way to confirm that products load from Apple's servers. Make sure the device is set up correctly for sandbox testing so that StoreKit uses the sandbox account for purchases. If products load against a local StoreKit configuration file but not against sandbox, that points back to identifiers, agreements, or product state in App Store Connect rather than to your code. If they load in sandbox but not in production, the issue is likely product approval state or propagation timing. Isolating which environment fails tells you which layer to fix. Testing in a clean, correctly configured sandbox is also the only way to validate the full purchase flow, so it is worth getting this environment right regardless of the current bug. On recent iOS versions the sandbox account is set under the developer settings rather than by signing out of the main App Store account, so check that the right sandbox identity is selected before concluding that products genuinely fail to load.
StoreKit needs to reach Apple's servers to return product information, so transient network problems or timing can cause products to appear briefly absent. On first launch with poor connectivity, the product request may fail and leave the paywall without prices until a retry succeeds. Confirm the test device has a working connection and try relaunching, since a subsequent request often succeeds once the network is available. There can also be a short delay between the SDK requesting products and StoreKit returning them; a paywall presented in that window might momentarily show placeholders. Superwall generally handles fetching products for its paywalls, but if you observe consistent failures only under specific network conditions, connectivity is worth ruling out before deeper investigation. Newly created products propagating through Apple's systems can also masquerade as a network problem, appearing intermittently until they are fully available everywhere. Distinguish a transient failure, which resolves on retry or after propagation, from a persistent one, which points to identifiers, agreements, or configuration. If retries under good connectivity still show no products, the cause is structural rather than transient, and you should return to the identifier and App Store Connect checks. The practical test is repetition: a problem that clears on the second or third launch is almost always timing or network, while one that never clears no matter how many times you relaunch is a configuration fault you will not fix by waiting.
Work the causes in order of likelihood to fix this efficiently. First, confirm every product identifier matches exactly across App Store Connect, Superwall, and any StoreKit configuration file, and that the running app's bundle ID owns those products. Second, verify the Paid Applications agreement is active and each product is fully configured, priced, and in a loadable state, allowing for propagation time on new products. Third, check whether a StoreKit configuration file in your scheme is overriding the product source and whether its contents match. Fourth, test on a real device with a proper sandbox Apple ID rather than the simulator. Fifth, rule out network and timing by retrying under good connectivity. To prevent recurrence, centralize and document your product identifiers so they cannot drift between App Store Connect, Superwall, and code, and add a QA step that verifies paywalls render live prices before every release. Remember the boundary: Superwall presents the paywall, but the products, agreements, and StoreKit configuration are entirely Apple's domain and your responsibility. Nearly every blank-paywall bug lives in that Apple layer, so keeping it clean is the durable fix. Working the list in this fixed order matters as much as the list itself, because each step is cheaper than the one after it, and stopping at the first check that fails usually resolves the problem without ever touching the more involved environment and timing investigations.
The paywall is presenting but StoreKit cannot return the products it needs. The most common cause is a product identifier mismatch between App Store Connect, Superwall, and any StoreKit configuration file. Other causes include an inactive Paid Applications agreement, products not yet in a loadable state, or a stale local StoreKit file.
Character for character, including capitalization and any suffixes, across App Store Connect, the identifiers registered in Superwall, and any StoreKit configuration file. StoreKit silently omits identifiers it does not recognize, so a single wrong character produces a blank product slot with no error. Also confirm the running app's bundle ID owns the products.
Yes. If the Paid Applications agreement in App Store Connect is pending, expired, or missing tax and banking information, in-app purchase products will not load. Verify the agreement is active and complete before investigating code, and also confirm each product is fully configured and priced.
Possibly. If a StoreKit configuration file is selected in your Xcode scheme, products come from that file instead of App Store Connect. If its identifiers do not match your paywall, prices appear blank. Check your scheme's run options and either align the file's contents or remove it to test against sandbox.
Use a real device signed in with a dedicated sandbox Apple ID, because the simulator can be unreliable for StoreKit product loading and purchases. If products load against a local StoreKit file but not in sandbox, the issue is in App Store Connect identifiers, agreements, or product state.
It can be. Newly created in-app purchase products take time to propagate through Apple's systems and may load intermittently until fully available. Combined with first-launch network hiccups, this can look like a persistent failure. Retry under good connectivity; if products still never load, return to identifier and agreement checks.