Bootstrap the public demo: Trusted Arbiter for interstitials

[antonurankar-moloco]

Summary

The first contents of this repository: a single-screen Trusted Arbiter demo for interstitials, with CloudX and AdMob loading in parallel, both fills becoming bids, CloudX.arbiter picking the winner, and the winner shown from a stored result so the show path makes no network call.

Interstitials only. Rewarded is the same flow plus one reward callback, and banners are a different shape entirely, so neither is repeated here.

78 files, of which most are the Flutter and Xcode scaffolding flutter create produced. The demo itself is seven Dart files.

What a reader is meant to copy

Everything under lib/cloudx/. None of those files builds a widget, and that is checkable: grep -rn "CloudX\.\|MobileAds\." lib/ui lib/main.dart returns only two strings printed on screen.

File	What it is
lib/cloudx/arbiter_interstitial_controller.dart	The integration. The whole load, arbitrate, show cycle and both SDKs' calls, in one file.
lib/cloudx/arbiter_events.dart	The callbacks the controller reports through.
lib/cloudx/sdk_startup.dart	Brings both SDKs up, in the order they have to come up in.
lib/cloudx/tracking_gate.dart	The iOS App Tracking Transparency gate.
lib/cloudx/cloudx_failure_text.dart	One line out of a CloudX failure, carrying the SDK's own name for the error code.
lib/cloudx/demo_config.dart	App key and ad unit ids, per platform. The first file to edit.
lib/ui/arbiter_screen.dart	Demo-only UI. Explicitly not for copying.

Decisions worth reviewing

• Google Waterfall is deliberately excluded on both platforms. It runs AdMob demand inside the CloudX auction, which is the opposite of what this demo shows: here AdMob is an external bid competing against CloudX. Shipping both would make the two bids the same demand. Leaving it out also frees google_mobile_ads from matching that adapter's exact Google Mobile Ads pin, which is why this app runs google_mobile_ads 9.1.0 while the internal demo is held at 7.0.0.
• BIGO is Android only. io.cloudx:adapter-bigo:6.0.1.0 is in android/app/build.gradle.kts and has no iOS counterpart, so the Gradle file lists one network more than the Podfile. It also needs cleartext traffic to 127.0.0.1, because the BIGO Ads SDK serves some creative assets from a loopback server on the device; that is android/app/src/main/res/xml/network_security_config.xml and the android:networkSecurityConfig attribute on <application>.
• io.cloudx.sample identity, matching the public Unity and React Native demos, so all three public demos are one dashboard app.
• No forced-no-fill switch. The Unity demo ships ArbiterConfig.ForceCloudXNoFill; this one uses real units only.
• The AdMob ids are Google's public test units, which report a revenue of 0.0. The price store discards 0.0, so the AdMob bid reaches the arbiter with no price and CloudX loses those rounds. That is called out in the README; point the demo at a paying unit to see prices compete.

Failure lines carry the error code name

Since cloudx_flutter 3.9.0 both CloudXError.codeName and CloudXInitializationResult.errorCodeName carry the native SDK's own name for the code, read from CloudXErrorCode.name on Android and +[CLXError nameForCode:] on iOS. cloudx_failure_text.dart formats both paths so they cannot drift: a round that did not fill reads No ad available. (NO_FILL[302]), and a rejected app key reads ... (NETWORK_CLIENT_ERROR[103]) rather than a bare number. The message is trimmed, because the Android initialize failure arrives with a trailing newline that otherwise pushed the code onto a line of its own.

The dev-setting commit is resolved

Earlier revisions of this branch resolved cloudx_flutter from a local pub host, because 3.9.0 was not published and the standing decision was that it never would be. Both of those have changed: cloudx_flutter 3.9.0 went to pub.dev on 2026-09-13, and commit 9917bd5 puts the manifest back to a plain cloudx_flutter: ^3.9.0 with pubspec.lock recording https://pub.dev and the sha256 of the published archive. Anyone can flutter pub get this branch now, and preflight-hermetic.sh --release passes rather than failing by design.

It was not undone with git revert 833a3e6. That revert conflicts, because pubspec.lock was rewritten twice after it, and its parent also carries the older ^3.8.0 pin and the pre-review Dart and Flutter floors that the first review round corrected. The manifest was edited and the lock regenerated, which is the path a7de163 documented inline.

What the loop review changed

Three rounds of Copilot plus a line-by-line pass and a loop check.

Commit	What
a7de163	The documented undo path for the dev setting did not work: git revert 833a3e6 conflicts on both files, and its parent carries ^3.8.0 and the pre-review SDK floors, so taking it would undo an accepted fix. Also stopped the README calling banners an "inline" flow, which is the SDK's word for the now-unexported CloudXAdView.
6f92fe1	Two cues from the public Unity demo: README screenshots out of docs/images/ beside the sections that explain them, and the iOS signing note moved from Versions into Required setup with the app key and bundle id, which is how that demo groups the three things a publisher changes.
bee0111	cloudx_failure_text.dart offered INVALID_APP_KEY[203] as its worked example while this PR's own validation records NETWORK_CLIENT_ERROR[103] for a rejected key. Now quotes codes this demo actually produces. Also records why tracking_gate.dart's check-then-listen is not the race two readers took it for.
9917bd5	Resolve cloudx_flutter from pub.dev now that 3.9.0 is published.
7cdf0e2	flutter build apk --release could not build at all: the BIGO network security config declared 127.0.0.1 with no includeSubdomains attribute, which Android lint reports as an error under lintVital, and that task runs on every release assemble. The attribute changes no behaviour (a literal address has no subdomains, and false is the default); lint only requires the choice to be explicit. The form now matches android/adapter-bigo/README.md in the monorepo, which has always carried it.

Left open for a human: the tracking_gate.dart thread, where the reviewer's race does not exist (no await between the read and the registration, and AppLifecycleListener fires onResume unconditionally on the transition to resumed) but the invariant was worth writing down.

One flag from comparing against the sibling public demos: both the public Unity and React Native demos ship First Look while this one ships Trusted Arbiter, and Flutter is the only one of five platforms with no integrations/first-look.mdx. The earlier flag about https://docs.cloudx.io/en/flutter/trusted-arbiter returning 404 is closed: cloudx-io/docs#434 merged on 2026-09-13 and that page is live.

Validation

Both platforms were run, not just built.

• flutter analyze — no issues
• Android, emulator API 36 and a physical Pixel 10 Pro: SDK initialized, Arbiter enabled: https://sdk.cloudx.io/arbitration in the logs, both sides filling (CloudX testbidder $0.0005, AdMob reservation campaign), arbiter: 2 bid(s) then platform=ADMOB, the AdMob interstitial displayed and closed, reportRevenueData(0.0 micros USD, PrecisionType.unknown) returned=true. On the Pixel the BIGO adapter is discovered at startup: network=Bigo Ads, adapterVersion=6.0.1.0, minimumSdkVersion=4.7.0.
• iOS, simulator iPhone 17: ATT answered before init, same full cycle, same result.
• Forced-failure runs on both platforms, with the ad unit and then the app key deliberately broken, confirming the named codes reach the screen: INVALID_AD_UNIT[300] on both, NETWORK_CLIENT_ERROR[103] for the Android initialize path. Those edits were reverted; git diff lib/cloudx/demo_config.dart is empty.
• qa/sdk/scripts/flutter/preflight-hermetic.sh --app <this repo> --release — exit 0, resolved hosted from https://pub.dev at 3.9.0, no path dependency into the monorepo.

Re-verified against the published package

After the switch to pub.dev, the whole thing was run again from a clean room: a fresh clone of this branch resolved with an empty PUB_CACHE, which created only a pub.dev entry and produced a byte-identical pubspec.lock. The published lib/, android/ and ios/ are identical to the flutter/sdk/3.9.0 tag by diff -r, the package's own pins are CloudXCore ~> 3.9.0 and io.cloudx:sdk:4.7.0, and ios/Podfile.lock was unchanged by pod install. One full arbiter round ran on an Android emulator and an iOS simulator booted for the run: two bids, ADMOB won, the interstitial shown and closed, reportRevenueData ... returned=true on both.

• flutter build apk --debug — built; the APK carries the BIGO resources and adapter classes, and res/xml/network_security_config.xml survives manifest merging.
• flutter build apk --release — failed before 7cdf0e2 on the lint error above, and now produces app-release.apk at 68.5MB.

[Copilot]

🟡 Changes recommended

Unresolved critical dependency, SDK constraint, signing, runtime, and platform metadata findings block approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a public Flutter demo integrating CloudX Trusted Arbiter with parallel CloudX/AdMob interstitial loading, winner selection, stored-result presentation, ATT gating, and native platform setup.

Changes:

• Adds arbiter controller, callbacks, configuration, tracking gate, and demo UI.
• Adds Android/iOS SDK, adapter, AdMob, ATT, and SKAdNetwork configuration.
• Adds documentation, dependencies, and Flutter project scaffolding.

Unresolved findings:

• Critical: pubspec.yaml uses a local-only dependency source (3 votes); SDK constraints conflict with the lockfile (3 votes); iOS signing hard-codes a team (1 vote).
• Moderate: Missing Google SKAdNetwork identifier (2 votes); controller show and in-flight state failures (2 and 1 votes); busy/load-button state issues (2 and 1 votes).
• Nit: README’s AdMob price example does not match the implementation (1 vote).

File summaries

File	Reviewed scope
README.md	Demo documentation
pubspec.yaml	Dependencies and SDK constraints
pubspec.lock	Locked dependency graph
lib/tracking_gate.dart	iOS ATT gate
lib/main.dart	Demo screen and lifecycle
lib/config/demo_config.dart	Platform ad configuration
lib/arbiter/arbiter_interstitial_controller.dart	Arbiter load, show, and revenue flow
lib/arbiter/arbiter_events.dart	Controller callbacks
ios/RunnerTests/RunnerTests.swift	iOS test scaffold
ios/Runner/SceneDelegate.swift	iOS scene delegate
ios/Runner/Runner-Bridging-Header.h	Swift bridging setup
ios/Runner/Info.plist	AdMob, ATT, and SKAdNetwork metadata
ios/Runner/Base.lproj/Main.storyboard	Main storyboard
ios/Runner/Base.lproj/LaunchScreen.storyboard	Launch screen
ios/Runner/Assets.xcassets/LaunchImage.imageset/README.md	Launch asset guidance
ios/Runner/Assets.xcassets/LaunchImage.imageset/Contents.json	Launch asset metadata
ios/Runner/Assets.xcassets/AppIcon.appiconset/Contents.json	App icon metadata
ios/Runner/AppDelegate.swift	iOS app delegate
ios/Runner.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings	Workspace settings
ios/Runner.xcworkspace/xcshareddata/swiftpm/Package.resolved	Swift package pins
ios/Runner.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist	Xcode workspace checks
ios/Runner.xcworkspace/contents.xcworkspacedata	Workspace references
ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme	Xcode scheme
ios/Runner.xcodeproj/project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings	Project workspace settings
ios/Runner.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved	Swift package pins
ios/Runner.xcodeproj/project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist	Xcode checks
ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata	Project workspace
ios/Runner.xcodeproj/project.pbxproj	iOS project configuration
ios/Podfile.lock	Locked CocoaPods
ios/Podfile	iOS pods and adapters
ios/Flutter/Release.xcconfig	Release Flutter settings
ios/Flutter/Debug.xcconfig	Debug Flutter settings
ios/Flutter/AppFrameworkInfo.plist	Flutter framework metadata
ios/.gitignore	iOS ignore rules
android/settings.gradle.kts	Android Gradle plugins
android/gradle/wrapper/gradle-wrapper.properties	Gradle version
android/gradle.properties	Android build properties
android/build.gradle.kts	Android repositories and build setup
android/app/src/profile/AndroidManifest.xml	Profile manifest
android/app/src/main/res/values/styles.xml	Light launch themes
android/app/src/main/res/values-night/styles.xml	Dark launch themes
android/app/src/main/res/drawable/launch_background.xml	Android launch background
android/app/src/main/res/drawable-v21/launch_background.xml	Android API 21 launch background
android/app/src/main/kotlin/io/cloudx/cloudx_flutter_public_demo/MainActivity.kt	Android entry point
android/app/src/main/AndroidManifest.xml	Android permissions and metadata
android/app/src/debug/AndroidManifest.xml	Debug manifest
android/app/build.gradle.kts	Android dependencies and adapters
android/.gitignore	Android ignore rules
analysis_options.yaml	Dart analyzer configuration
.metadata	Flutter project metadata
.gitignore	Repository ignore rules

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (4)

README.md:128

• This shared example says both lines display loaded: <network> $<price>, but the AdMob callback in main.dart:337 reports only _adMobNetworkName; AdMob intentionally has no bid price. Split the examples or explicitly limit the price suffix to CloudX so the screen guide matches the implementation.

| `CloudX` / `AdMob` | That side's last event: `loading`, `loaded: <network> $<price>`, `load failed: ...`, `showing`, `closed`. |

lib/arbiter/arbiter_interstitial_controller.dart:160

• The AdMob show call can fail through its awaited platform Future (for example when the stored interstitial has expired). With no catch, _nextWinner has already been cleared but _isShowing remains true, so _show() gets an uncaught error and the controller cannot reload. Catch this failure, dispose/reset the AdMob state, and return false (or route it through the existing show-failed event).
  lib/arbiter/arbiter_interstitial_controller.dart:74
• The screen uses isBusy to enable Load both, but this getter excludes _isShowing even though load() rejects calls while an ad is visible. Pressing the button during the show therefore overwrites the status lines without starting a load. Include _isShowing in the busy state or gate the button on isShowing.
  lib/main.dart:162
• load() intentionally starts only the missing side, but this unconditional update marks both sides as loading. After a one-sided failure, the retained ad emits no new loaded callback, so its status remains loading even while it is still held as a bid/winner and the diagnostic screen becomes misleading. Update only the side(s) actually being requested or expose per-side loading state.

• Files reviewed: 46/74 changed files
• Comments generated: 6
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Unresolved build, dependency, and interstitial state-management issues remain.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (5)

lib/arbiter/arbiter_interstitial_controller.dart:130

• show() leaves _isShowing false while this readiness call is awaited, so the Load button/API can start another _maybePrepareWinner() round against the same fills. That second result can overwrite _nextWinner; if it selects CloudX, it refers to the ad whose first show is still being prepared or consumed. Mark the show as in-flight before awaiting readiness (and clear it on the stale/failure paths), or otherwise serialize loading/arbitration with this check.
  lib/arbiter/arbiter_interstitial_controller.dart:74
• isBusy omits _isShowing, so after a show has started the screen's Load both button remains enabled. Tapping it rewrites the UI to loading/waiting for both sides to settle, while load() immediately returns because an ad is showing, leaving misleading status until another cycle. Include the showing state in the busy predicate.
  lib/main.dart:162
• This unconditionally reports both networks as loading, but load() deliberately reloads only missing fills. After a CloudX win/close, for example, the retained AdMob fill is not requested again and emits no new loaded event, so the demo can permanently display AdMob: loading while that bid is included in the next arbitration. Update only the sides actually being loaded, or expose the controller's per-side state to the screen.
  pubspec.yaml:10
• The package advertises support for Flutter 3.38.1/Dart 3.10, but the committed resolution requires Flutter >=3.44.0 and Dart >=3.12.0. A user on the advertised minimum cannot resolve this lockfile, so either raise these environment constraints to the resolved floors or regenerate dependencies that meet the advertised range.
  pubspec.yaml:23
• As committed, a fresh clone following the README cannot run flutter pub get: the direct SDK dependency is hard-wired to an HTTP pub server on 127.0.0.1:8080, and the lockfile records that same local source. This is explicitly a temporary development setting, but it makes the public demo unusable until the SDK is published; please keep this setting out of the mergeable public-demo commit (or otherwise provide a resolvable published dependency).

• Files reviewed: 46/74 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

One or more issues must be addressed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (2)

lib/main.dart:175

• show() returns false both for a stale winner and when another show is already in progress. This branch treats the latter as stale and calls _load(), which immediately no-ops because controller.isShowing is true, while the UI is left saying it is reloading. Check controller.isShowing before taking the stale-winner recovery path.
  lib/main.dart:166
• controller.load() retains the losing ad and reloads only the missing side, so after a CloudX win the next load does not emit an AdMob load callback (and vice versa). Resetting both rows to loading leaves the retained side permanently misreported as loading, which makes this diagnostic screen incorrect. Update only the side that is actually being loaded or expose/use controller state for the held fills.

• Files reviewed: 46/74 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Unresolved moderate issues remain in lib/main.dart, along with a README correctness nit.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (4)

Previously missed (2) — in code that hasn't changed since the last review.

lib/main.dart:166

• load() intentionally starts only the missing side, and after a none result it may only rerun arbitration while both fills are still held. Resetting both rows to loading here therefore leaves the held side permanently showing loading because it emits no load callback (and a winnerless retry may emit only an arbiter event). Update only the side(s) actually being loaded, or expose that state from the controller, so the diagnostic rows stay accurate.
  lib/main.dart:175
• A second tap while the first show() is awaiting readiness makes show() return false because controller.isShowing is still true. This path treats that normal in-flight rejection as a stale winner, changes the rows to loading, and calls load() while the controller is still showing, so load() is a no-op and the UI remains stuck. Check controller.isShowing before entering the stale-winner reload path (or disable Show while it is in flight).

README.md:34

• This promises that the checked-in Google test units will make CloudX lose, but the validation for this PR reports the opposite (platform=ADMOB). With zero ILRD revenue there is no meaningful price comparison, but the eventual winner can still depend on arbiter fallback/tie behavior; the README should not state a deterministic CloudX loss.

Which is why the AdMob ids checked in here make a poor price demo: Google's test
units report a revenue of 0.0, the price store drops any revenue of 0.0, and the
AdMob bid therefore reaches the arbiter with no price at all. Expect CloudX to
lose those rounds. Point the demo at a real AdMob unit that pays to see prices
compete.

lib/main.dart:81

• When ATT is denied, this branch returns before MobileAds.instance.initialize() is started, but _adMobSdkStatus remains initializing forever. That makes the demo report an operation that never began; set the AdMob status to an explicit blocked/not-initialized value alongside the CloudX status.

• Files reviewed: 46/74 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Four unresolved moderate review findings remain in the controller and demo UI.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

lib/main.dart:162

• This resets both rows even though controller.load() intentionally starts only missing sides. After an ad is consumed, the other SDK still holds its fill, and after a none result both fills can already be held; in those cases no onAdLoaded callback follows for the retained side, so its status remains loading indefinitely and the diagnostic screen is incorrect. Preserve the retained status or expose/report per-side loading state and update only the sides that are actually requested.

lib/arbiter/arbiter_interstitial_controller.dart:237

• An AdMob InterstitialAd is not valid indefinitely (loaded interstitials expire after about an hour), but this controller treats any non-null _adMobAd as a current bid. If the screen is left open or this side loses several rounds, an expired object can be selected here and show() fails instead of refreshing AdMob. Track the load timestamp/expiry and discard or reload stale ads before building bids.
  lib/main.dart:163
• controller.show() claims _isShowing synchronously, but the widget can still have the old frame where Load both is enabled until an SDK callback triggers a rebuild. A tap in that window writes the loading/waiting rows before controller.load() returns because it is showing, leaving the diagnostic stuck or misleading. Guard the UI mutation with the controller's current state, not only the button's last build.

• Files reviewed: 46/74 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Unresolved moderate issues remain in show recovery and demo state handling; initialization documentation also needs clarification.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (4)

Previously missed (1) — in code that hasn't changed since the last review.

lib/main.dart:162

• _load() marks both rows as loading, but controller.load() intentionally starts only missing sides. After an AdMob win is closed the CloudX fill is retained, and after a none/arbiter retry both fills can already be held, so no CloudX load callback follows and the row remains loading even after arbitration completes. Update only the sides actually being loaded (or expose a controller state/event for a re-arbitration) instead of resetting both rows here.

README.md:46

• This copy-and-run instruction omits the required SDK initialization performed in main.dart: the controller does not initialize either SDK, and its own comments note that CloudX must already be initialized before loading. A consumer following this sentence can call load() before CloudX is ready, and on iOS also needs to complete ATT first; mention initializing Mobile Ads and CloudX (after the ATT decision where applicable) before calling load()/show().

A real integration copies the first three files and calls `load()` and `show()`.

lib/arbiter/arbiter_interstitial_controller.dart:177

• The show slot is claimed before this call, but the actual CloudX show invocation is not awaited or protected by the error handling above. If the platform-channel call throws (or its returned Future fails), show() completes with an error while _isShowing remains true and the held ad is not cleared, so later load() calls are rejected permanently and the demo cannot recover. Handle this call like the readiness path: release the slot/fill and report onAdShowFailed on failure.
  lib/main.dart:81
• When ATT is denied or restricted, this branch returns before MobileAds.instance.initialize() is called, but _adMobSdkStatus remains initializing forever. That makes the diagnostic screen report an operation that was never started; set the AdMob status to an explicit blocked/not-initialized value along with the CloudX status.

• Files reviewed: 46/74 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Two moderate findings remain unresolved, along with one dependency-version documentation nit.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

lib/main.dart:162

• load() is intentionally incremental: it may reload only the missing side, or just rerun arbitration when both fills are already held (see arbiter_interstitial_controller.dart:87-112). This unconditional update makes both rows say loading even when neither row is loading or when one side remains held, and no callback will restore that retained side's status; after a none/arbiter-failure retry the screen can stay stuck showing work that is not happening. Preserve the existing row values or expose per-network loading state and only mark the sides that actually started loading.

lib/arbiter/arbiter_interstitial_controller.dart:177

• The readiness call is protected, but this actual CloudX show invocation is not. If the listener claim or showInterstitial platform call throws synchronously, _isShowing remains true after _nextWinner was cleared, so later load()/show() calls are rejected forever and no failure event reaches the UI. Handle invocation failures here by releasing the show slot and reporting onAdShowFailed, just as the readiness failure path does.
  pubspec.yaml:25
• The PR description still refers to cloudx_flutter 3.8.0 and says the dev block should be reverted to ^3.8.0, while this checked-in manifest and lockfile consistently resolve 3.9.0. Once the local host is removed, following the stated revert would not reproduce this dependency graph; update the description/revert instructions or align the manifest and lockfile.

• Files reviewed: 46/74 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Three moderate issues remain in startup error handling, lifecycle handling, and refused-state UI reporting; two documentation nits also remain.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (4)

Previously missed (1) — in code that hasn't changed since the last review.

lib/cloudx/sdk_startup.dart:89

• This doc comment links to canLoadAds, but SdkStartupResult has no such member, so generated API docs point readers to a nonexistent contract. Describe the actual conditions instead of linking an undefined property.

README.md:55

• These instructions name the wrong files to drop. From the five-file list above, an app that already initializes CloudX and handles ATT should remove sdk_startup.dart and tracking_gate.dart but retain demo_config.dart; the current wording tells readers to drop tracking_gate.dart and demo_config.dart while keeping startup, so the copied integration is not usable as documented.

**Take fewer and it will not build.** The controller reports through
`arbiter_events.dart`, and `sdk_startup.dart` calls `tracking_gate.dart`. If
your app already initializes CloudX and answers the ATT prompt, drop those last
two and keep the first three.

lib/cloudx/sdk_startup.dart:34

• run() documents that it never throws, but TrackingGate.request() performs awaited platform-channel calls here without any error handling. If the ATT plugin reports a native/channel failure, _start() rejects and the screen never receives a startup result or failure status; handle this failure and return/report a failed startup outcome just as CloudX.initialize is handled below.
  lib/cloudx/tracking_gate.dart:55
• There is a lifecycle race between this state check and registering the listener: if the app resumes in that window, no later onResume event is guaranteed, so _waitUntilActive() can remain pending forever and the demo stays at "requesting tracking permission". Recheck binding.lifecycleState after installing the listener and complete the completer when it is already resumed.

• Files reviewed: 48/76 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The unresolved moderate startup error-handling finding can leave initialization incomplete.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (6)

Previously missed (1) — in code that hasn't changed since the last review.

lib/cloudx/sdk_startup.dart:90

• This doc comment links to canLoadAds, but SdkStartupResult has no such member and the symbol does not exist elsewhere in the project. The generated API documentation is therefore broken and the comment suggests a gating API that this result does not expose; describe cloudXInitialized directly instead.

README.md:165

• This table says both platform rows show loaded: <network> $<price>, but the AdMob loaded callback passes only _adMobNetworkName (arbiter_interstitial_controller.dart:380); no AdMob price is displayed. Please document the two formats accurately so readers do not expect a value that the screen cannot show.

| `CloudX` / `AdMob` | That side's last event: `loading`, `loaded: <network> $<price>`, `load failed: ...`, `showing`, `closed`. |

README.md:34

• The README says to expect CloudX to lose with these test units, but the validation described for this PR reports an ADMOB winner with the checked-in units. That makes the demo guidance misleading; describe the zero revenue as meaning there is no learned AdMob price, without predicting which bid wins.

Which is why the AdMob ids checked in here make a poor price demo: Google's test
units report a revenue of 0.0, the price store drops any revenue of 0.0, and the
AdMob bid therefore reaches the arbiter with no price at all. Expect CloudX to
lose those rounds. Point the demo at a real AdMob unit that pays to see prices
compete.

README.md:55

• This copy instruction says an app can drop sdk_startup.dart after only initializing CloudX and answering ATT, but that file also initializes Google Mobile Ads. Following the documented recipe leaves AdMob uninitialized before InterstitialAd.load() is used; require both SDKs to be initialized, or tell the reader to retain/replace the AdMob initialization.

**Take fewer and it will not build.** The controller reports through
`arbiter_events.dart`, and `sdk_startup.dart` calls `tracking_gate.dart`. If
your app already initializes CloudX and answers the ATT prompt, drop those last
two and keep the first three.

README.md:50

• The PR description's “What is in the diff” section still points at lib/arbiter/..., lib/config/..., lib/tracking_gate.dart, and calls lib/main.dart the demo screen, but the checked-in files are under lib/cloudx/ and lib/ui/ (main.dart is only the entry point). Please update the description so its file map matches the code reviewers and users will actually find.

| [`lib/cloudx/arbiter_interstitial_controller.dart`](lib/cloudx/arbiter_interstitial_controller.dart) | The integration. The whole load/arbitrate/show cycle and both SDKs' calls, in one file. |
| [`lib/cloudx/arbiter_events.dart`](lib/cloudx/arbiter_events.dart) | The callbacks the controller reports through. |
| [`lib/cloudx/sdk_startup.dart`](lib/cloudx/sdk_startup.dart) | Brings both SDKs up, in the order they have to come up in. |
| [`lib/cloudx/tracking_gate.dart`](lib/cloudx/tracking_gate.dart) | The iOS App Tracking Transparency gate. |
| [`lib/cloudx/demo_config.dart`](lib/cloudx/demo_config.dart) | App key and ad unit ids, per platform. The first file to edit. |
| [`lib/ui/arbiter_screen.dart`](lib/ui/arbiter_screen.dart) | Demo-only UI. Ignore it when reading the integration. |
| [`lib/main.dart`](lib/main.dart) | `runApp`, nothing else. |

lib/cloudx/sdk_startup.dart:34

• SdkStartup.run() promises never to throw, but TrackingGate.request() is the only startup await still outside a handler. Either ATT platform-channel call can reject (for example if the plugin/native API is unavailable); that rejection escapes _start() and leaves the screen's initial statuses forever. Catch it and return a refused/failed result before starting either SDK.

• Files reviewed: 48/76 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

CloudX initialization and ATT failures can still escape the startup error handling and leave the demo stuck.

Get a fresh assessment by requesting another Copilot review.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (2)

README.md:57

• This copy guidance only mentions an existing CloudX initialization and ATT prompt, but sdk_startup.dart also initializes Google Mobile Ads. A consumer following these instructions can omit MobileAds.instance.initialize() when removing the startup helper; include Google Mobile Ads in the prerequisite.

If your app already initializes CloudX and answers the ATT prompt, drop
`sdk_startup.dart` and `tracking_gate.dart` and keep the rest.

lib/cloudx/sdk_startup.dart:37

• The same never throws contract is still violated by TrackingGate.request(): it awaits platform-channel status/prompt calls without handling rejection. If ATT fails before returning a status, _start() aborts and the screen remains at requesting tracking permission; convert this to a refused/failed startup result (and log it) instead of letting the future escape.

• Files reviewed: 50/78 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Two moderate startup error-handling issues remain unresolved, and the failure-code documentation nit needs clarification.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (3)

lib/cloudx/cloudx_failure_text.dart:10

• This copy-facing example conflicts with the demonstrated bad-app-key behavior in the PR description, which reports NETWORK_CLIENT_ERROR[103] for the Android initialize path. Either use the observed code here or explicitly explain the platform/error-path distinction; otherwise readers can be led to diagnose a different failure code than the demo displays.
  lib/cloudx/sdk_startup.dart:37
• run() promises never to throw, but TrackingGate.request() is awaited outside any error handling. A plugin/platform-channel failure while reading or requesting ATT will reject run() and _start() does not catch it, leaving the startup rows at their initial values and producing an unhandled async error. Catch this path and return/report an explicit startup failure (or handle it in the caller).
  lib/cloudx/sdk_startup.dart:66
• SdkStartup.run promises never to throw, but this CloudX.initialize await is still outside a try/catch. A native/platform-channel exception rejects _start() before it can update either SDK status, leaving the screen stuck at its initial rows and violating the startup result contract. Catch the exception and return a failed SdkStartupResult (or otherwise surface it as an initialization failure).

• Files reviewed: 50/78 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The ATT lifecycle race and retry-time winner replacement remain unresolved, and the platform-specific failure-code example needs clarification.

Get a fresh assessment by requesting another Copilot review.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (1)

lib/cloudx/arbiter_interstitial_controller.dart:88

• load() does not guard an already prepared winner. If one side failed and the other produced _nextWinner, a caller that retries load() before showing starts the missing side; when it fills, _handleCloudXLoaded/the AdMob callback calls _maybePrepareWinner() and can replace the winner that was ready to show. The demo UI currently prevents this, but the copied controller exposes load() publicly, so keep the prepared-winner state immutable until show() consumes it.

• Files reviewed: 50/81 changed files
• Comments generated: 2
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The broad cross-platform SDK and native-project changes warrant final human review, and a documentation nit remains.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (1)

lib/ui/arbiter_screen.dart:57

• This comment says the controller is built once both SDKs are up, but SdkStartup.run() deliberately returns before MobileAds.initialize() completes and only awaits CloudX initialization. The controller can therefore be created while AdMob is still initializing; describe that it is created after CloudX is ready while AdMob initialization continues in parallel, so copied integrations do not infer a stronger ordering than the code provides.

• Files reviewed: 50/81 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Resolve the unavailable cloudx_flutter dependency source and preserve a prepared winner when load() is called again.

Get a fresh assessment by requesting another Copilot review.

Review details

Files not reviewed (2)

• ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata: Generated file
• ios/Runner.xcworkspace/contents.xcworkspacedata: Generated file

Suppressed comments (3)

README.md:58

• SdkStartup.run also starts Google Mobile Ads via MobileAds.instance.initialize() (sdk_startup.dart:47), but this copy instruction only says an existing app must initialize CloudX and answer ATT before dropping sdk_startup.dart. Following it can remove the only AdMob initialization while the controller still calls InterstitialAd.load; mention Google Mobile Ads here or require callers to initialize it separately.

If your app already initializes CloudX and answers the ATT prompt, drop
`sdk_startup.dart` and `tracking_gate.dart` and keep the rest.

README.md:127

• This sentence reverses the ordering stated immediately before it: the example correctly says the ATT prompt must be answered before CloudX initialization, but then says “initialize first” without making clear that this is the mistake being warned against. A reader can follow that as an instruction and initialize while ATT is still not determined, causing the exact IDFA/dnt behavior this setup avoids; phrase it as a conditional warning.

   The prompt is answered while `CloudX SDK` still reads `not initialized`. That
   order is the point: initialize first and every request that session goes out
   without an IDFA and with `dnt = 1`.

lib/cloudx/arbiter_interstitial_controller.dart:88

• load() is still callable while a winner is prepared. In the one-sided-fill case, arbitration can store a CloudX winner while the AdMob side is null; calling load() then starts AdMob, and its callback invokes _maybePrepareWinner(), which can overwrite or clear the existing winner. The UI disables this path, but the public controller contract should preserve a prepared winner for callers that invoke load() directly; return early when _nextWinner != null (or otherwise isolate a new round).

• Files reviewed: 50/81 changed files
• Comments generated: 1
• Review effort level: Lite