Most apps with a subscription offering typically have a notion of "pro", or paid, features. One way to sell those? By showing some component in the interface that upsells the value of some particular feature:

• A banner in settings that shows off pro features.

• Or, maybe a workout app would have a lock icon over workouts that are part of a premium plan.

That’s where getPresentationResult shines in our SDK. Using it, you can tell whether or not a paywall would've shown for a particular placement. This API doesn’t actually show a paywall. Instead, it simply tells you, “If you tried to show a paywall here, what would happen?”

With that in hand, you can make smart UI decisions — like whether to show that in-app banner, a modal encouraging users to upgrade, or even dim certain components based on campaign logic configured entirely in Superwall.

Let’s walk through why this is useful, when to use it, and how to implement it in your app today.

Wait, why not just use entitlements?

At first glance, it might seem like something you could just handle with a basic entitlement check. But here’s the difference:

Entitlement checks tell you what the current access level is.

But, getPresentationResult centralizes the logic about who should be upsold, what campaign rules apply, and whether a paywall would actually show — all in one place.

In practice, that means:

• You can always change targeting logic without shipping a new app update.

• You don’t hardcode paywall access rules in the client (if they are this level, or that level, etc).

• You stay in sync with the actual paywall experience — because it’s literally using the same decision engine under the hood,

Showing and hiding upsell chrome

Let’s check out Superwall's resident example app, Caffeine Pal. In it, we've got some "quick log" buttons that are part of the pro plan. If they aren't on a paid plan, we'll add a lock icon over them:

If users aren't on a pro plan, a lock icon shows over the log buttons.

The buttons themselves? They register a placement called caffeineLogged, and we don't have to change anything about them for all of this to work:

Button("Log") {
    Superwall.shared.register(placement: "caffeineLogged") {
        store.log(amountToLog)
    }
}

That's perfect for showing the paywall, and we can change whether or not that should show a paywall in the Superwall dashboard at any point (all over the air, no app update needed). But, what about that lock icon? How do we know when to show it?

That’s a perfect use case for getPresentationResult.

private func queryPresentationResult() {
    Task {
        let res = await Superwall
                        .shared
                        .getPresentationResult(forPlacement: "caffeineLogged")

        switch res {
        case .paywall(let exp):
            self.showLock = true
            print("Result: Showing paywall for \(exp)")
        case .placementNotFound:
            self.showLock = false
            print("Result: No placement for caffeineLogged")
        case .noAudienceMatch:
            self.showLock = false
            print("Result: No matching audience.")
        case .holdout(_):
            self.showLock = false
            print("Result: User is in a holdout.")
        case .paywallNotAvailable:
            self.showLock = false
            print("Result: Paywall is unavailable.")
        }
    }
}

Now, you can easily base the lock icon's appearance based on the same logic Superwall uses to determine whether or not a paywall would show. This is our SDK working together perfectly — the button itself will show a paywall if it needs to, log caffeine if they are pro, the lock icon follows the same logic and all of that can be controlled over the air when you edit the campaign that caffeineLogged belongs to.

Digging into PresentationResult

If you need to get more fine-grained information about the presentation result, look no further than its return type, PresentationResult. As you saw in the example above, it reports back the reason a paywall would show or not show. To distill it down for scenarios like ours, you'd basically want to show upsell chrome when you hit a paywallresult:

Of note, you'll get noAudienceMatch when they are a paying customer.

It's a flexible API, and there are several compelling use-cases for it. Whether you need an inline banner for premium-only sections of an app, maybe a conditional tooltip that might guide users to try locked features, or even during free trials, soft gates, and educational moments — the API works for all of them. Hiding and showing premium upsells like the one below becomes trivial:

An upsell in settings.

Wrapping up

Knowing the result of a paywall presentation attempt is one of the most powerful (and in my opinion, underrated) tools in the Superwall SDK. It lets you write smarter, more adaptable UI by deferring all the logic of “should this user see a paywall?” over to us. After all, you don’t ever want to duplicate campaign logic on the client. You can simply just ask: what would happen if I tried to show a paywall right now?

I hope this tip helps you out, and as always — go sign up for a free Superwall account if you haven't yet. Then, check our installation guide to be up and running in minutes.