Superwall lets you remotely configure every aspect of your paywall — helping you find winners quickly.
SuperwallKit is an open source framework that provides a wrapper around WebKit for presenting and creating paywalls. It interacts with the Superwall backend letting you easily iterate paywalls on the fly in Swift or Objective-C!
- If you're upgrading from v3.x of our SDK, please follow our Migration Guide
| Superwall | |
|---|---|
| ✅ | Server-side paywall iteration |
| 🎯 | Paywall conversion rate tracking - know whether a user converted after seeing a paywall |
| 🆓 | Trial start rate tracking - know and measure your trial start rate out of the box |
| 📊 | Analytics - automatic calculation of metrics like conversion and views |
| ✏️ | A/B Testing - automatically calculate metrics for different paywalls |
| 📝 | Online documentation up to date |
| 🔀 | Integrations - over a dozen integrations to easily send conversion data where you need it |
| 💯 | Well maintained - frequent releases |
| 📮 | Great support - email a founder: jake@superwall.com |
The preferred installation method is with Swift Package Manager. This is a tool for automating the distribution of Swift code and is integrated into the swift compiler. In Xcode, do the following:
- Select File ▸ Add Packages...
- Search for
https://github.com/superwall/Superwall-iOSin the search bar. - Set the Dependency Rule to Up to Next Major Version with the lower bound set to 4.0.0.
- Make sure your project name is selected in Add to Project.
- Then, Add Package.
Cocoapods is an alternative dependency manager for iOS projects. For usage and installation instructions, please visit their website. To include the Superwall SDK in your app, add the following to your Podfile:
pod 'SuperwallKit', '< 5.0.0'
Next, run pod repo update to update your local spec repo.
Then, run pod install from your terminal.
Sign up for a free account on Superwall and read our docs.
You can also view our iOS SDK docs. If you'd like to view it in Xcode, select Product ▸ Build Documentation.
Read our Kodeco (previously Ray Wenderlich) tutorial: Superwall: Remote Paywall Configuration on iOS.
Check out our sample apps for a hands-on demonstration of the SDK:
Please see the CONTRIBUTING file for how to help.
IP collection is off by default. It only runs when the backend turns on
attributionOptions.mmp.enabled in the app's config. When it's off, no IP lookups are made and no ipV4/ipV6
attributes are exposed.
During enrichment, the SDK also starts a best-effort request to
https://v4.superwall-enrichment.com/api/v1/enrich. It sends no user attributes or API key
to this endpoint. The host is kept separate from the main enrichment API on purpose: it
only has an IPv4 address (no AAAA record), so the request always goes out over IPv4. It has
no development version, so the request is only made with the release network environments.
Timestamps may be sent with or without milliseconds.
It also asks https://beacon-v6.superwall.com/api/v1/enrich for the IPv6 address. That
host is reachable over both IPv4 and IPv6 (Cloudflare can't make a proxied host IPv6-only),
so the SDK makes this request over a connection that may only use IPv6 (NWConnection
with the IP version set to IPv6). On a network without IPv6 the request fails, and the
device simply has no ipV6. The endpoint must answer GET with
{"device": {"ipAddress": <IPv6>, "ipAddressObservedAt": <ISO 8601>}}, like the IPv4 one.
This lookup isn't made on watchOS.
The existing enrichment API continues to provide geo and demand scoring.
It must also return the observed ipV4 or ipV6 and corresponding ISO 8601
ipV4ObservedAt / ipV6ObservedAt timestamp to capture that connection's address.
The SDK exposes ipV4, ipV6, ipV4ObservedAt, and ipV6ObservedAt as device
attributes when available. They remain separate: an IPv4 response does not erase IPv6.
The IPv6 address is often one of the device's temporary privacy addresses, so it changes
more often than IPv4. These are public network egress addresses, potentially shared through NAT or VPN.
The extra request never blocks configuration or purchases. While the MMP is on, a lookup
can start whenever device attributes are read, at most once every 15 minutes, or a minute
after a failed one. The IPv4 and IPv6 lookups keep separate schedules. The IPv4 collector is session-local; the existing enrichment cache may restore a still-fresh
observation after relaunch. All observations are omitted from device attributes after 15
minutes; network changes can make them stale sooner.
Any ipAddress the enrichment API returns is passed through unchanged.
They are not proof of identity. Downstream consumers must preserve the timestamps and apply
their own freshness policy. Wrapper SDKs receive this behavior when they adopt a native
SDK release containing it.