Add the CloudX First Look demo app for React Native

[antonurankar-moloco]

Public copy of the CloudX First Look reference integration for React Native, with Google Ad Manager as the fallback.

CloudX gets the first chance to fill on every ad opportunity. If CloudX does not fill, the app falls back to GAM for that opportunity only, and the next opportunity starts back at CloudX. Exactly one SDK owns the placement at any moment — the two are never loaded in parallel.

What's here

One banner and one interstitial. That is deliberate: the point is the pattern, not format coverage.

File	What it is
src/config/adUnits.ts	Placements, timing constants, required dashboard setup
src/firstlook/useFirstLookBanner.ts	The banner refresh cycle
src/firstlook/FirstLookBannerSlot.tsx	How that cycle is rendered — visible slot plus hidden preload slot
src/firstlook/useFirstLookInterstitial.ts	The simpler fullscreen case
App.tsx	Minimal host screen

Builds against published artifacts

Nothing resolves from source. cloudx-react-native@3.4.7 from npm, CloudXCore 3.4.5 (exact) from CocoaPods, io.cloudx:sdk:4.4.0 from Maven, React Native 0.76.2.

CloudXGoogleWaterfallAdapter is deliberately absent — it runs AdMob demand inside the CloudX auction, which is the opposite of First Look, and it pins an exact Google-Mobile-Ads-SDK version that fights react-native-google-mobile-ads.

Verified

Android 15 emulator and iPhone 17 Pro simulator (iOS 26.5), both platforms, both formats.

Happy path — CloudX initializes, the banner fills, the interstitial displays.

Fallback path — forced by pointing the slot at ad unit ids that cannot resolve. GAM filled the banner and showed the interstitial on both platforms, and the cycle returned to CloudX afterwards rather than staying on GAM:

22:26:09.784  CloudX  -> INVALID_AD_UNIT
22:26:09.8xx  GAM     -> filled, swapped in
   (REFRESH_DELAY_MS = 30s)
22:26:41.801  CloudX  -> INVALID_AD_UNIT    <- back to CloudX

That last line is the claim the whole pattern rests on: a CloudX miss costs one opportunity, not the placement.

tsc --noEmit clean; eslint 0 errors.

Known issue, not fixed here

The CloudX SDK's own banner auto-refresh is enabled on the demo placement, which this pattern
requires to be off — the app owns the refresh cycle, and a second timer swaps an ad in mid-cycle.
Observed on guDml31r4Ys6O6HroPJia:

[AdViewManager] [guDml31r4Ys6O6HroPJia] Starting auto-refresh
[AdViewManager] [guDml31r4Ys6O6HroPJia] Banner refresh scheduled in 30s

This needs a dashboard change (banner ad unit refresh rate -> 0); there is no client-side fix.
CloudXBannerAd.stopAutoRefresh() resolves the ad unit id against the programmatic overlay ads
created through that API, and a CloudXBannerView-rendered banner is not in that registry, so the
call silently does nothing. The README and adUnits.ts now state this as a requirement to be
satisfied rather than claiming it already is. The iOS placement was not checked.

Identifiers

Matched to the public Unity demo (cloudx-io/cloudx-unity) so both public demos are the same app:
io.cloudx.sample on both platforms, and Unity's CloudX app keys and placements. adUnits.ts
carries all five of Unity's formats; only banner and interstitial have consumers here.

Trade-off accepted: CloudX reporting cannot separate RN traffic from Unity traffic, and the two apps
overwrite each other on a device that has both.

The GAM ids were already identical — RN resolves them through TestIds, Unity hardcodes them.

Notes for review

• AppDelegate.swift forces test mode unconditionally, so the app serves test creatives against the shared demo placements rather than burning real fill. Remove it for a production integration.
• Ad unit ids and app keys here are the shared CloudX demo placements, already used by the public ObjC, Swift and Android sample apps.