Best Offerwall SDKs for iOS Apps in 2026

What is the best offerwall SDK for an iOS app?

The best offerwall SDK for an iOS app is the one that installs with the package manager you already use, supports your deployment target, declares its data honestly in a privacy manifest, and credits rewards through signed server-to-server callbacks instead of events on the device. Among SDKs with current iOS releases in November 2026 are the Moonetix iOS SDK (2.0.0, iOS 13+), from an affiliate network that credits users through signed postbacks, Unity Offerwall (formerly Tapjoy, version 14.8.0, iOS 13+), DT Offer Wall from Digital Turbine (3.68.1, iOS 15+), AdGem (3.5.0, iOS 15+), BitLabs (4.2.0), and ayeT-Studios (1.0.4). Offer supply in your users’ countries decides what each one earns, so test two before you commit.

This guide is about choosing. For step-by-step Swift code, see How to add an offerwall to an iOS app in Swift. Building for Android too? The best offerwall SDKs for Android runs the same checks on Maven packages.

How to choose an iOS offerwall SDK

An SDK becomes part of your app binary, and Apple holds you responsible for it. Its User Privacy and Data Use page says plainly that “developers are responsible for all code included in their apps.” Check these points before you add one:

The first four take minutes to check yourself: open the package repository, read Package.swift, download the xcframework, and open the privacy manifest. That is what we did below. What is an SDK? covers the general trade-offs.

iOS offerwall SDKs compared

We read each provider’s iOS docs, its Swift package or podspec, and, where the package ships a binary, the privacy manifest inside it. Moonetix comes first and the rest are listed alphabetically, not ranked. Checked on November 11, 2026.

We make Moonetix, so we list it first. Every fact about the other networks comes from their own sites and docs, checked on the date shown.

Docs often lag the packages. AdGem’s iOS page still describes 3.0.0 while its package repository has 3.5.0, and BitLabs’ guide shows 4.1.0 against a 4.2.0 tag. Pin a version and read the release notes before you update.

What each provider documents

• Moonetix. The Moonetix iOS SDK docs list iOS 13 or newer, Xcode 16 or newer, iPhone and iPad, and only UIKit and WebKit with no third-party dependencies. The SDK is free under the Apache License 2.0.
• AdGem. The AdGem iOS SDK docs list iOS 15.0 or higher, Xcode 14 or higher, and the AdGem Swift package. They say the SDK includes the IDFA only if your app already has ATT authorization, and that without it attribution falls back to fingerprint matching and SKAdNetwork.
• ayeT-Studios. The iOS SDK v2 docs install from the ios-sdk-v2-repo package and warn that the SDK will not initialize if your placement’s package name does not match your app. Its source code is public, so you can read what it collects from the device.
• BitLabs. The BitLabs iOS SDK docs recommend Swift Package Manager over CocoaPods and say about a deprecated in-app reward handler: “We highly recommend using server-to-server callbacks instead.”
• DT Offer Wall. Digital Turbine’s iOS integration page lists iOS 15, Xcode 14.1, and the FairBidSDK pod, and asks you to set Allow Arbitrary Loads to Yes under App Transport Security and to tick Requires full screen. The Offer Wall ships inside the DT FairBid SDK.
• Unity Offerwall. Unity’s iOS quickstart says the SDK supports iOS 13.0, supports Swift Package Manager from version 13.4.0 via the Tapjoy swift-packages repository, and recommends waiting for the ATT completion handler before connecting.

Weighing Tapjoy against other options in more depth? Tapjoy alternatives covers that question.

ATT, IDFA and SKAdNetwork

The App Store Review Guidelines, in 5.1.2(i), say: “You must receive explicit permission from users via the App Tracking Transparency APIs to track their activity.” Apple defines tracking as linking data from your app with other companies’ data for targeted advertising or ad measurement, or sharing it with data brokers. Without permission, the advertising identifier is all zeros.

For an offerwall SDK, that leaves three cases:

• The SDK never reads the IDFA. You add no ATT prompt for it. The Moonetix docs state this for its SDK.
• The SDK reads the IDFA only after permission. AdGem, BitLabs, and the ayeT-Studios code work this way. If you already show the ATT prompt for other reasons, they pick up the ID; if you do not, they work without it and attribution relies on other signals.
• The SDK expects a prompt. If you show one, add an NSUserTrackingUsageDescription string to Info.plist and show the prompt before you open the wall, as Unity and AdGem describe.

Never tie rewards to the prompt. Guideline 5.1.2(i) says apps may not require users to enable tracking to “receive monetary or other compensation”, and Apple’s FAQ answers “No” to incentivizing users to allow tracking.

SKAdNetwork is a separate topic. Apple’s Configuring a source app page says an app that displays signed ads must list ad network IDs in Info.plist under SKAdNetworkItems, and that “ad networks are responsible for publishing or providing their ad network IDs.” None of the offerwall setup guides above asks you to add SKAdNetwork IDs for the wall itself, so ask your provider before you paste a long list. SKAdNetwork and ATT explained covers how the two fit together.

Privacy manifests and your App Privacy label

Apple’s privacy manifest documentation says third-party SDKs can contain a PrivacyInfo.xcprivacy file that records the data they collect, and the NSPrivacyTracking key says whether the SDK uses data for tracking. The same page says that if the user has not granted tracking permission, network requests to the domains listed in NSPrivacyTrackingDomains fail.

What we found inside the frameworks:

• Moonetix 2.0.0 sets NSPrivacyTracking to false and lists user ID, device ID, coarse location, and product interaction, none used for tracking. Its docs say the device ID is for fraud prevention.
• Unity Offerwall 14.8.0 sets NSPrivacyTracking to true, lists one tracking domain, and marks device ID, user ID, product interaction, purchase history, and advertising data as used for tracking.
• AdGem 3.5.0 sets NSPrivacyTracking to true and marks device ID and user ID as used for tracking.
• DT FairBid 3.68.1 sets NSPrivacyTracking to false but marks device ID as used for tracking.
• BitLabs and ayeT-Studios ship as Swift source packages, and we found no privacy manifest in either repository. Ask them for their data list before you fill in your label.

Apple’s third-party SDK requirements list the SDKs that must ship a signed manifest. No offerwall SDK is on that list. Your App Privacy label must still include the data every SDK in your app collects.

App Store guidelines 3.1.1 and 3.2.2 for rewarded offers

The App Review Guidelines never name offerwalls. These are the rules that decide how one may work, checked on November 11, 2026:

Kids apps are out: guideline 1.3 says Kids Category apps should not include third-party advertising, and 5.1.4 says the same for apps intended primarily for kids. Describe the Earn feature in your App Review notes. Can you put an offerwall in an iOS app? walks through every rule with a sample review note.

Credit rewards on your server, not in the app

Several SDKs offer an in-app reward event, such as AdGem’s offerwallRewardReceived delegate. It is handy for a quick test, but anything that runs on the device can be tampered with on a jailbroken phone. For a real economy, the flow is the same with every provider:

1. Your app asks your server to open the wall for the signed-in user.
2. The provider sends a signed callback to your server when an offer completes.
3. Your server checks the signature, skips any transaction ID it has seen, and adds the currency.
4. On a reversal, your server takes the currency back.
5. The app reloads the balance when the wall closes.

Unity’s self-managed currency docs describe an MD5 verifier on each callback and retries every five minutes for up to four days. Postback security lists what to verify, and how to prevent duplicate reward credits covers the transaction ID check. Price earned coins against your in-app purchase packs with the virtual currency calculator.

How to add Moonetix to your iOS app

If you pick Moonetix, you need one server endpoint and a few lines of Swift.

1. Apply as a publisher at moonetix.com. Every application is reviewed by hand, and once you are approved, apps you add are live right away.
2. Add your app in the dashboard and set your currency name, icon, conversion rate, user split, rounding, and wall design with the live preview.
3. Add MoonetixOfferwall with Swift Package Manager or CocoaPods and call Moonetix.configure(appId:) at launch. The Swift guide has the full code.
4. Add a token endpoint on your server that calls POST /v1/session with your API key. The app opens the wall with that single-use token, so no key ships in the app.
5. Credit currency only from the signed postback, then use “Open as a test user” and “Send a test postback” in the app’s Integration tab, as in Test your app before launch. Copy the four data types from the SDK docs into App Store Connect.

Honest limits: offers depend on each user’s country and device, and some campaigns run only on Android, so an iOS-only audience may see fewer offers. Users on VPNs, proxies, Tor, or data center networks are blocked, and end users must be at least 16, so the wall does not belong in a kids app. The Flutter, React Native, and Unity packages bundle the same iOS SDK; see Moonetix for mobile apps for the full picture.

Frequently asked questions