Skip to main content

Overview

Banner ads are rectangular ads displayed in a portion of the screen. They can be used in both UIKit and SwiftUI.

Key Features

  • Can be fixed at the top, bottom, or middle of the screen
  • Supports both image and video ads
  • Supports both UIKit and SwiftUI
  • Ad event handling through delegates
Use test unit ID in development environment: PUBLIC_TEST_UNIT_ID_320_100

UIKit Implementation

In UIKit environment, implement banner ads using the AdropBanner class.

Basic Implementation

AdropBanner Initialization

String
required
Unit ID created in Ad Control Console

Load Ad

Call the load() method to request an ad after adding the banner to the screen.
Call load() when the banner is visible on screen. Loading when not visible may result in inaccurate impression measurements.

Set Context ID

You can set a Context ID for contextual targeting.

SwiftUI Implementation

In SwiftUI environment, implement banner ads using AdropBannerRepresented.

Basic Implementation

Delegate Handling

You can handle ad events through delegates.

Set Context ID


Objective-C Implementation

How to implement banner ads in Objective-C environment.

Basic Implementation

Set Context ID


Delegate Methods

The AdropBannerDelegate protocol handles ad lifecycle events.

onAdReceived (Required)

Called when ad is received successfully.

onAdFailedToReceive (Required)

Called when ad fails to load.
AdropErrorCode
Error code indicating the type of error. See Reference for details.

onAdImpression (Optional)

Called when ad is displayed on screen.

onAdClicked (Optional)

Called when user clicks on the ad.

onAdVideoStart (Optional)

Called when a video ad starts playing.

onAdVideoEnd (Optional)

Called when a video ad finishes playing.

Closure Callbacks

As an alternative to delegates, you can use closure-based callbacks.
If both a delegate and closures are set, both will be called.

Lifecycle Management

destroy()

When you no longer need the banner, call destroy() to release its resources — WebView, tracking, and any active video playback are torn down actively. destroy() is idempotent, so calling it multiple times is safe. The instance cannot be reused after destroy.
Skipping destroy() when the view controller deallocates leaves the WebView and related resources uncollected, which can cause memory leaks and performance degradation — especially impactful for video banners.

Ad Sizes

Banner ads require view size to match the size set in the unit.

Common Banner Sizes

UIKit

SwiftUI


Best Practices

1. Memory Management

Call destroy() when the view controller is deallocated to release banner resources.

2. Screen Visibility

Load ads when the banner is visible on screen.

3. Reuse the Banner Instance

Keep a single AdropBanner instance and call load() on it whenever you need a new ad. Do not create a new AdropBanner for every refresh. Recreating the banner for each ad request allocates a new WKWebView and its associated WebContent process each time. Under frequent refresh conditions — especially with video banners — this accumulates resource usage and can degrade rendering performance.
onAdReceived fires again on each subsequent load() call, so your existing delegate handles the new ad automatically.

4. Error Handling

Implement appropriate error handling when ad loading fails.

Test Unit IDs

Use the following test unit IDs during development and testing.

Usage Example


Video Playback Control

For video banner ads, you can manually control video playback using play() and pause().

play()

Resumes video playback. Call this when the banner becomes visible again — for example, after a popup is dismissed or the app returns from the background.

pause()

Pauses video playback. Call this when the banner is hidden by a popup or the app enters the background.

Example: Background/Foreground Handling

play() and pause() only affect video banner ads. They have no effect on image banners.

Custom Click Handling

You can take control of ad click behavior by using useCustomClick. When enabled, the SDK will not automatically open the destination URL on click, and you can handle it yourself.

useCustomClick

When useCustomClick is true, the SDK will not open the destination URL automatically when the ad is clicked. The onAdClicked delegate callback will still fire, and you can use the open() method or handle navigation yourself.

open()

Opens the destination URL of the ad. Can optionally pass a custom URL.

Batch Loading (loads)

Use AdropBanner.loads(...) to request multiple banner ads in a single batched call. This is useful for building carousels, paginated feeds, or prefetching a pool of ads.

Signature

Usage

Delegate Methods

The singular onAdReceived(_:) / onAdFailedToReceive(_:_:) callbacks are not invoked on the loads path. Use onAdsReceived(_:) / onAdsFailedToReceive(_:) as the sole batch signals.

Constants

Int
default:"5"
Upper bound on ads returned from a single loads(...) call.

Constraints

  • Maximum 5 ads per call. If the server returns more, only the first 5 are delivered.
  • Backfill is not applied. If no direct ads fill, onAdsFailedToReceive is called with ERROR_CODE_AD_NO_FILL regardless of backfill configuration.
  • Do not call destroy() inside onAdsReceived. Attach each banner to the view hierarchy first, then call destroy() when the view controller deallocates.
  • onAdsReceived fires as soon as ad data is applied, matching the single load() contract — the creative paints shortly after you add the banner to a view hierarchy.
  • Hold strong references to the returned banners (e.g., store them on the view controller). If they deallocate before being attached, they’re silently dropped.

Backfill Ads

When backfill ads are enabled, backfill ads are automatically loaded when direct ads are unavailable. Use the isBackfilled property to check if the ad is a backfill ad.
To use backfill ads, add the AdropAds-Backfill dependency. See Getting Started.

Preloading Backfill Ads (preload)

Starting with SDK 1.17.0, you can use AdropBanner.preload() to preload a backfill banner ad. When a banner that you load() with the same unit ID and the same size gets no direct ad and falls back to a backfill ad, it displays the preloaded ad right away instead of requesting a backfill ad again. load() still requests a direct ad first, regardless of preload. If a direct ad is displayed, the preloaded ad is kept as is. If you don’t call preload, the behavior is the same as before.

Requirements

  • Both adrop-ads and adrop-ads-backfill must be 1.17.0 or later.
  • Preload fetches a backfill ad only when the server has told the app that there are no direct ads to show right now. Otherwise, it ends with ERROR_CODE_AD_PRELOAD_SKIPPED without requesting a backfill ad. This is a normal result in apps that have direct ad campaigns.
  • Right after the app is installed, right after you change the App Key, and right after you switch to a different user with setUID, preload ends with ERROR_CODE_AD_PRELOAD_SKIPPED until the server response arrives.
  • With test unit IDs, preload always ends with ERROR_CODE_AD_PRELOAD_SKIPPED.

Usage

Call preload right before you open the screen that contains the banner. A preloaded ad is discarded after 30 minutes if it isn’t used, so call preload only for banners you’re about to display. You don’t need to wait for the result before calling load(). If the ad is still being fetched, load() waits for that result and uses it. delegate is held weakly. To receive the result callback, keep the delegate object alive until the result arrives.
To use the preloaded ad, make the banner’s frame size match the adSize you passed to preload before you call load().

When a Preloaded Ad Is Used

  • Same unit ID and same size: When you call load(), the banner’s frame size must match the adSize you passed to preload. If you size the banner only with Auto Layout, its size may not be determined yet when you call load(). If the size differs, the preloaded ad is kept as is, and load() requests a backfill ad as usual.
  • Not tied to a screen: preload doesn’t take a view controller. An ad preloaded on a different screen is also used by the banner you load().
  • Used only once: A preloaded ad is gone once a single load() uses it. To preload again, call preload again.
  • Lifetime and count: An ad that isn’t used within 30 minutes is discarded. Only 1 ad is kept per unit and size, and banners keep up to 5 different unit/size combinations. When there are more than 5, ads are discarded starting with the one received first.
  • Calling again: Calling preload again with the same unit and size doesn’t make a new request. If an ad has already been preloaded, onAdPreloadReceived is called without a new request; if one is still being fetched, you get that load’s result (success or failure). You can’t use preload to refresh an ad. However, if the user consent status has changed in the meantime, the existing ad is discarded and a new one is fetched.
  • Consent status changes: If the user consent status changes after an ad is preloaded, that ad isn’t used by load().

Result Delegate Methods

The following optional methods have been added to AdropBannerDelegate. Each time you call preload, one of the two is called once on the main thread. No other delegate methods are called for preload. The second argument, contextId, returns the value you passed to preload as is (default: empty string). It isn’t used to select a preloaded ad.

Failure Codes

Don’t call preload again right away inside the failure callback. If the result doesn’t change — for example, when the backfill dependency is missing — the calls repeat endlessly. Call it again later, such as before you open the next screen.

Next Steps

Native Ads

Implementing customizable native ads

Interstitial Ads

Implementing full-screen interstitial ads

Targeting Settings

Setting up user attributes and contextual targeting

Reference

Classes, delegates, error codes reference