One integration that carries every format and every network.
The SkyBoosts SDK is the only app-side component most publishers need. It renders every supported ad format natively on mobile, runs the mediation layer that lets all your demand compete in one decision, collects and passes consent signals, and reports impression-level events back to the auction and to your reporting. Adding a placement is a dashboard change, and new networks ride the release cadence you control.
Test placements · marked creative before launch
Everything the auction needs, already wired in.
The SDK ships as one dependency with the full feature set on board, no format packs to license separately, no mediation layer to bolt on, no measurement bridge to build.
Every format, native render
Rewarded, interstitial, banner and MREC, native, playable and offerwall render through the same SDK surface, with placement rules surfacing as plain objects in code. Each format page carries its specifics, and format mixes are yours to tune per placement. A game can run rewarded plus interstitial plus banner without a second dependency.
Mediation built in
The unified auction and the automated waterfall both live inside the SDK, so every network you connect competes from day one. Network adapters arrive through SDK releases you control the timing of. There is no mediation product to license alongside, and no adapter patching on your side.
Open Measurement signals
OMID is pre-integrated on mobile formats, exposing viewability and verification signals to whichever measurement partner your buyers use. Verification runs through the same SDK that renders the ad, so there is no separate measurement package to integrate and keep current. Buyers see third-party-verified delivery from their first campaign.
Consent handled end to end
Consent signals travel with every bid request and are enforced by the auction, so child-directed traffic is treated as such from the first impression to the last report line. What the signals forbid, the auction refuses to buy. There is no path around the checks.
Test mode from the first build
Test and live placements coexist in one build, so a team can validate new inventory while the shipped app keeps earning. Test placements produce no billable events, so validation never contaminates financials. Switching a placement to live demand is a dashboard toggle.
Impression-level events
Request, bid, win, render, completion, every event is timestamped and lands in the same reporting the dashboard and the reporting API read from. Events carry the placement and impression identifiers, so client-side analytics joins cleanly onto server-side revenue. Nothing was aggregated away before it reached you.
Mobile first, television included.
The SDK covers the platforms where your users actually are, and the support matrix, minimum OS versions included, is maintained in the SDK reference so it always matches the binaries that shipped.
| Platform | Use | Minimum versions | Notes |
|---|---|---|---|
| iOS | Mobile apps | Published in SDK reference | All formats, mediation, OMID |
| Android | Mobile apps | Published in SDK reference | All formats, mediation, OMID |
| Android TV / Google TV | CTV apps | Published in SDK reference | CTV video formats, SSAI fallbacks |
| Roku · Fire TV · tvOS | CTV apps | Confirmed during onboarding | SSAI-led integration paths |
Mobile platforms get the full in-app SDK experience: every format, mediation and measurement. On television the integration path depends on how the platform handles video, Android TV and Google TV apps can run the SDK directly with server-side ad insertion as a delivery mode, while platforms like Roku, Fire TV and tvOS are integrated SSAI-first, with our team handling manifest manipulation and beacon forwarding. Either way the auction, the policy engine and the reporting are the same ones your mobile inventory uses, and one account sees both.
Integrate in the environment you already build in.
Wrappers are thin layers over the same native API, so behavior, events and configuration are identical across engines, a placement that works in a native build works the same way through a wrapper.
Unity
For the majority of mobile game teams, integration happens where the game is built. The wrapper exposes placements, load and show calls, and reward callbacks as first-class engine objects. Supported Unity LTS versions ship alongside each release.
Flutter and React Native
Apps built on cross-platform frameworks integrate through wrappers that keep the SDK's event surface intact, so Dart or JavaScript code sees the same lifecycle a native integration sees. Wrapper states, including anything in active development, are published with each release.
Native iOS and Android
The primary integration path, with the full API surface and the fastest access to new features. Wrappers follow it, which is why behavior stays identical across environments, there is one implementation underneath, not four.
Footprint, permissions and data
Binary size and performance
Added binary size, startup impact and memory profile are measured per release and documented in the changelog. The numbers you plan your build against are the numbers that ship, and release-to-release movement is called out when it is material.
Permissions
The SDK requests only what ad serving requires on each platform: network state, the advertising identifier where consent permits it, and media rendering. Every permission is documented with the reason it exists, so your privacy labels and store submissions describe the SDK accurately the first time.
Data collected
Technical bid data, device and app identifiers, and consent signals, the minimum the auction and measurement need to function. The categories are enumerated in the privacy notice, not summarized, and the enumeration is what your privacy counsel should read.
Privacy controls
The COPPA child-directed flag, GDPR consent string pass-through and US state privacy signals including GPP are set in code, travel with every bid request, and are enforced by the auction. Reporting keeps child-directed inventory separable, so audits have something to audit.
Test mode and debugging
Test placements return marked test creative so integration can be validated without touching live campaigns. Debug logging exposes the auction lifecycle on device, request sent, bids received, winner, render state, and release builds strip debug output automatically. Test creative carries a visible test marking, so a screenshot is enough to prove which mode a build ran in.
Versioning and security
Releases follow a published cadence with a documented deprecation window, and every version ships with a changelog that says what moved and why. Distribution binaries are signed. A software bill of materials is available to enterprise publishers as part of security review.
From dependency to first ad request in one sitting.
Add the dependency
Pull the SDK from the package registry for your platform. Quickstarts with copy-ready snippets are in the documentation, and the reference apps show a working integration you can run immediately.
Initialize with your account ID
One initialization call attaches the app to your SkyBoosts account and picks up configuration, placements and consent defaults. Configuration is fetched at launch, so most changes after that never require a new binary.
Define placements
Create rewarded, interstitial, banner, native, playable or offerwall placements in the dashboard, then reference their IDs in code. Each placement carries its own format settings, floors and policy, so tuning one never disturbs the others.
Validate in test mode
Run marked test creative through every placement, inspect the lifecycle logs, confirm the consent flags behave as your compliance team expects, then switch placements to live demand when everything checks out.
The SDK, asked and answered.
The reference breaks the footprint down per format, so a team integrating only banners can see what that path costs before opting into heavier formats. Measure against the release you actually ship, and re-measure when you adopt a major version, that is when the number moves.
No. Mediation is part of the one SDK: the unified auction and the automated waterfall both run inside it, and network adapters arrive through the same release cycle. There is no second dependency and no second integration project.
You enable it in the dashboard, set its tier and timeouts, and it joins the auction in the next SDK release you adopt. Your app store review cadence stays under your control the whole time.
When a signal is missing or conflicting, the SDK fails conservative: the request carries what is known, and the auction applies the stricter treatment rather than guessing. The privacy notice documents each signal, what it gates, and where it is enforced.
Android TV and Google TV apps run the SDK directly. Other TV platforms are integrated SSAI-first with our team, where the SDK plays a smaller role and server-side ad insertion does the delivery; the auction and reporting are identical either way.
Yes. The documentation ships reference apps per platform showing a complete working integration, placements, consent handling, test mode and event handling, and the integration team reviews your first build before it goes to production.
Integrate once, reach every format.
Get the SDK, quickstarts and reference for your platform combination from the integration team.
iOS · Android · Android TV · Google TV