Skip to main content
An Ad Unit defines an ad placement and format in your app. For the DARO 2.0 SDK, copy the Ad Unit Key from the updated dashboard. This is different from the app’s Integration Key. API parameters such as adUnitId, unitId, and key, and example placeholders such as YOUR_AD_UNIT_ID, keep their names but take that Ad Unit’s Ad Unit Key. Existing integrations using Ad Unit IDs remain supported. Do not confuse reporting or callback identifiers with the key for a new integration.

Before You Begin

Important: SDK initialization is requiredBanner and native ads must be rendered only after SDK initialization completes. Rendering an ad component before initialization may cause an initialization error.Other formats such as interstitial and rewarded video ads must also be loaded after initialization.

Requirements

  • Android minSdkVersion: 23
  • iOS 15.1 or later
If your Android app’s minSdkVersion is below 26, configure core library desugaring in the app module (android/app/build.gradle or build.gradle.kts). See Android Getting Started for the setup.Without it, a class loading error can occur while reading the advertising ID on devices below API 26.The Expo config plugin does not apply this setting, so Expo projects must configure it too.
[email protected] uses Android so.daro:daro-sdk 2.0.2 and iOS DaroAds 2.0.1.The wrapper and native SDK versions are managed independently.
Please double-check that your app-ads.txt file is configured correctly.

Supported Ad Formats

  • Banner/MREC
  • Native
  • Interstitial
  • Rewarded
  • Light Popup

Installing the Package

Rebuild your Android and iOS apps after updating the SDK. Run pod install from ios/ for iOS, and use prebuild or EAS Build to apply native changes in Expo projects.

Configuring an Expo Project

The unified SDK ships an Expo config plugin. Provide your Integration Key in the app config and the plugin applies the Android and iOS native setup during prebuild.
DARO native modules are not available in Expo Go. Use a development build or a prebuilt app.
1

Add the plugin to your Expo config

Keep your existing Expo config and add the DARO entry to expo.plugins. Each platform takes a single Integration Key.
app.json
On iOS you can override the App Tracking Transparency prompt with attUsageDescription. A default message is used when it is omitted.
2

Run prebuild or EAS Build

If your project uses a dynamic Expo config, manage the app identifier through your existing Expo/EAS configuration.
Remove the 1.x key files and previous Expo key settings, then use daroIntegrationKey for each platform. For an existing app, follow the migration guide in order.
After configuring the Expo plugin, continue to Initializing the SDK.

Resolving SafeDK Build Errors

If an Android Release build fails with a Configuration Cache error in a safedk* or process...Manifest task, update to [email protected] or later. For Expo, add the following option to the Android settings in the existing react-native-daro entry in expo.plugins. Keep your Integration Key and iOS settings.
Run npx expo prebuild to apply the native configuration again, then run a Release build. The generated project uses Android SDK 2.0.2, Gradle plugin 2.0.3, and daro.safedkConfigurationCacheWorkaround=true. EAS Build runs prebuild automatically when its build input does not include the android/ and ios/ directories. If you include existing native directories, run npx expo prebuild yourself before building. See Expo’s EAS Build documentation for details. Use false to disable the workaround. Omitting the option preserves the existing Gradle value; it does not turn off a previously enabled setting. Use Boolean true or false, rather than strings such as "true". For React Native CLI projects without the Expo config plugin, update the Gradle plugin to 2.0.3 and add daro.safedkConfigurationCacheWorkaround=true to android/gradle.properties. See the SafeDK error section in Android Getting Started for the exact locations and setup.

Configuring a React Native CLI Project

If your project does not use the Expo config plugin, apply the build tools and Integration Key setup from Android Getting Started and iOS Getting Started. On Android, add the so.daro plugin and the so.daro:daro-sdk dependency to the app module. Match the Android SDK version specified on this page for the React Native package. Also add these React Native settings to android/gradle.properties, merging the entries with any existing ignore list.
Use Kotlin Gradle plugin 2.2.20 or later. On iOS, use the package’s CocoaPods dependency. Follow iOS Getting Started to configure DaroIntegrationKey, SKAdNetworkItems, the tracking permission message, and the post_install hook, then run pod install from ios/. Keep the existing React Native post_install settings and add the hook to the same block.

Initializing the SDK

initialize() completes after the native SDK finishes initialization and applies the latest mute setting. Load the first ad or render ad components only after await initialize() succeeds. If initialization fails, the Promise rejects; handle the failure before retrying and loading ads. Complete your app’s consent flow before initialization and pass the user’s choice and your app’s applicability decision. The privacy values below must come from your app; the example does not assume opt-in. GDPR accepts optIn, optOut, notApplicable, or unknown; CCPA accepts optIn, optOut, or notApplicable; COPPA accepts child or notChild. Set COPPA before initialization. Include any previously supplied consent string when updating its status. Use the code below to initialize the SDK. Supply privacy as a stable object after the consent flow completes; creating a new object on each render would repeat this initialization effect.

Configuring Ad Audio

Starting with 2.0.1, the React Native SDK defaults to muted ads (true). No additional setting is required to keep this default. If your app needs ad audio, call setAppMuted(false) before loading the first ad.
You can also change the setting after initialization. To mute ads loaded afterward, call:
setAppMuted(muted: boolean): Promise<void> can be called before, during, or after initialization. Before or during initialization, the latest value is retained and applied before initialization completes. The latest value also survives JavaScript reloads while the app process remains running. Completion of setAppMuted() means the setting was stored or passed to the initialized SDK. Wait for initialize() to succeed before loading the first ad.
Actual audio playback depends on the creative and ad demand source. Ads with their own mute options or creatives without audio may remain silent even when you pass false. Immediate audio changes to already-loaded ads are not guaranteed.

Best Practices

Managing SDK Initialization

Recommendations for managing the SDK efficiently and avoiding errors.
  1. Call initialize() at app startup
    • Initialize the SDK at your app entry point (App.js or index.js)
  2. Track initialization state
    • Keep the initialization result in state so you can control when ads render
  3. Guard every banner and native ad component with conditional rendering
    • Make sure ad components never render before initialization completes

Next Steps

Once integration and initialization are complete, continue to the guide for the ad format you want to use.