Most of the time, people have a fairly strong network connection. Most of the time. What do you do about the other times, though?

Here, we'll lay out some fundamental approaches to handling those situations, and explain how the Superwall SDK was designed to function under them.

How Superwall handles poor connectivity

Even under poor network condition, the Superwall SDK ensures that your app remains functional. Our SDK is largely powered via a configuration object that is fetched from our servers, which contains all sorts of useful information about your paywalls, products and more.

In the event of a dropped connection, Superwall tries to fetch the configuration again. During those times, you'll likely want to know how:

• Superwall handles subscription state.

• And, how you should handle paywall presentation.

Let's start with the user's subscription status. If a user is actively subscribed and the SDK has previously fetched or cached the configuration — then paywalls will still present as expected.

However, if the configuration can’t be retrieved due to a lack of connection, Superwall will attempt to fetch it again after one second. If still unsuccessful, the SDK tracks a timeout event, triggers the onSkip handler with the reason userIsSubscribed and then proceeds with the designated feature block or closure:

let handler = PaywallPresentationHandler()
handler.onSkip { reason in
    // Reason will be `userIsSubscribed`
}

Superwall.shared.register(event: "caffeineLogged", handler: handler) {
    // And this block will be fired
    store.log(amountToLog)
}

For users without an active subscription, Superwall takes a different approach.

The SDK will retry the network calls for up to one minute in an effort to retrieve the configuration. If the connection is still unavailable after this period, it'll invoke the onError handler with an error code of noConfig:

let handler = PaywallPresentationHandler()

// After timeout was unsuccessful and a paywall is presented
// We'll hit `onError`
handler.onError { error in
    // Error will indicate there is no configuration
}
Superwall.shared.register(event: "caffeineLogged", handler: handler) {
    // This will *not* be fired
    store.log(amountToLog)
}

Given this information, you may be wondering if there is a time to fallback and use your own native paywall. In short, yes - there are cases where you might consider it. Specifically, for error codes 103, 104 and 106:

• Code 103: This means there was no UIViewController (or platform equivalent) to present a paywall from.

• Code 104: Here, Superwall couldn't fetch its configuration. Superwall's CDN could be having issues, or more likely — there is no internet connection.

• Code 107: The paywall was unavailable to present.

• Code 106: Finally, this error indicates the webview failed to load.

For example, on iOS the onError handler can be cast to NSError, allowing you to check for these error codes. When present, consider presenting your own paywall. Also, if you need to get a quick native paywall going on iOS, check out our primer on creating basic paywalls up using StoreKit Views.

Fortunately, it's rare that you'll encounter these issues in production often. But at Superwall, we know that connections can and do drop, and hitting an error is going to happen at some point. We've built and designed these mechanisms to keep your app running smoothly when they do.