[BUG] Paywall presentation is delayed and paywall sometimes dismisses unexpectedly

[burakgomec]

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate
• I have attempted to reproduce the issue and include an example project.

General information

• Superwall version: 4.16.1
• iOS version(s): **iOS 26.5.2 **
• CocoaPods/Carthage version (if applicable): N/A (Swift Package Manager)
• Xcode version: 26.1
• Devices/Simulators affected: All
• Reproducible in the demo project? No
• Related issues: None found

Describe the bug

After upgrading from a previous Superwall SDK version to 4.16.1, we started experiencing two intermittent issues with paywall presentation in production.

1. The paywall sometimes takes approximately 5–6 seconds or longer to appear after triggering its presentation.
2. In some cases, the paywall is presented successfully but then dismisses/closes by itself without any user interaction.

Both behaviors are intermittent and do not occur on every attempt.

These issues were not observed before upgrading to Superwall 4.16.1 with the same paywall flow.

Steps to reproduce

1. Trigger a Superwall paywall presentation.
2. Observe the time it takes for the paywall to appear.
3. Repeat the flow multiple times.
4. In some attempts, the paywall takes approximately 5–6+ seconds to appear.
5. In other attempts, the paywall appears normally but then dismisses itself without any user interaction.

We have not yet identified a reliable reproduction pattern for either issue.

Expected behavior:

The paywall should be presented promptly after triggering the presentation and should remain visible until the user explicitly dismisses it or completes/cancels the relevant flow.

Actual behavior:

The paywall sometimes takes 5–6+ seconds to appear. In other cases, it appears but unexpectedly dismisses itself without any user interaction.

Other Information

The issues started after upgrading the Superwall iOS SDK to 4.16.1.

The same paywall configuration and presentation flow were used before and after the SDK upgrade.

The issue is occurring in production and appears to be intermittent.

I have attached screen recordings demonstrating both behaviors:

• Delayed paywall presentation (5–6+ seconds)
• Paywall dismissing unexpectedly without user interaction

I can provide additional logs, Superwall configuration details, or a sample project if needed.

Video.mov

[linear-code]

SW-5740

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[yusuftor]

Hi, please can you link to a user account within superwall who has experienced this problem so we can check the logs. Also, what version of the SDK were you on before you updated? Does this occur in the latest 4.16.2?

[burakgomec]

Hi, thanks for looking into this.

The user only provided me with their RevenueCat App User ID: 320d9ac512c04ca7b245038a65fe6fc7. I don't have a Superwall user link for them, and I'm not sure how to get one — could you tell me where I can find the corresponding Superwall user?

Specifically:

Can you search the Superwall dashboard by RevenueCat App User ID, or does it need to be the Superwall App User ID / alias ID?
If it needs to be the Superwall ID, where exactly in the dashboard do I search for a user, and is there another way to correlate them (e.g. by the App Store transaction ID or the purchase timestamp)?

On versions: I was on 4.0.0 before updating to 4.16.1, and the issue only started after the update. I haven't tested 4.16.2 yet — I'll update and report back.

In the meantime, would you recommend rolling back to 4.0.0 until this is resolved? If so, is there anything I should watch out for when downgrading (breaking changes, entitlement/subscription-status behaviour, cached paywall data)?

[yusuftor]

Thanks for the details.

Finding the user

The dashboard searches by the Superwall App User ID or alias rather than RevenueCat IDs. However, if you're following our recommended RevenueCat setup, you'll be calling Superwall.shared.identify(userId:) with the same app user ID you give RevenueCat, in which case the two IDs are the same string. Just open the Users page in the dashboard, paste 320d9ac512c04ca7b245038a65fe6fc7 into the search, open the user, and send us the URL of that page.

If you're not calling identify, the user is anonymous in Superwall under an alias ($SuperwallAlias:...) and there's unfortunately no way to look them up by the RevenueCat ID or transaction. In that case, let me know your app name and the approximate time of the recordings and we'll try to find the session from our side. Going forward I'd also recommend calling identify with the RevenueCat app user ID so the two accounts stay linked.

On the two symptoms

A few questions that would really help narrow this down:

1. Are you using a PurchaseController with RevenueCat, and if so, where do you set Superwall.shared.subscriptionStatus? The SDK waits for the subscription status to be set before presenting a paywall (up to 5 seconds, after which presentation fails). If you only set it after RevenueCat's network fetch of CustomerInfo completes, presentation can stall for roughly the delay you're describing. Setting it immediately on launch from RevenueCat's cached customer info avoids that wait.
2. For the unexpected dismissals — could the affected users already have an active subscription (resubscribed, purchased on another device, restored, family sharing)? The SDK automatically dismisses a presented paywall when it learns the user already has the entitlements that paywall unlocks, which looks exactly like a paywall closing on its own. If that's what's happening, that user's event feed in the dashboard will show a restore event followed by paywall_close with a restored result — easy to confirm once we have the user link.
3. How are you presenting the paywall — register(placement:), or via SwiftUI? If you're driving presentation from your own SwiftUI state, a view re-render that resets that state can also drop a presented paywall.

If you can reproduce it with options.logging.level = .debug set in SuperwallOptions and attach the console output, that would tell us a lot too.

On rolling back

I wouldn't recommend going back to 4.0.0: you'd be giving up around 40 releases of crash, StoreKit, and networking fixes. That said, if this is actively hurting you in production, a temporary downgrade is safe – there are no breaking API changes within 4.x and cached paywall data is simply re-downloaded – so there's nothing specific to watch out for beyond losing those fixes. But ideally we pin this down on 4.16.3 first with the logs and user link above.