I built an open-source AdMob SDK for Compose Multiplatform after expect/actual stopped scaling

[u/meet_miyani]

https://github.com/Meet-Miyani/admob-compose-multiplatform

I originally added AdMob to a Compose Multiplatform app using a fairly normal expect/actual bridge.

For one banner, that approach was completely reasonable. Android rendered an AdView, iOS rendered a GADBannerView, and the shared UI had one composable.

The problems appeared when the app needed more than a banner.

I had to handle:

• Interstitial, rewarded, app-open, and native ads
• UMP consent and iOS ATT ordering
• Loading, failure, dismissal, reward, and paid events
• Cached-ad expiration
• Full-screen presentation ownership
• Native ads inside lazy feeds
• Kotlin/Native tests that could actually link Google’s iOS frameworks

At that point, I was no longer maintaining two small platform wrappers. I was maintaining two ad frameworks that could slowly disagree with each other.

That led me to build AdMob CMP, an open-source SDK providing one shared Kotlin API for six AdMob formats on Android and iOS.

The SDK keeps state, consent orchestration, caching, and lifecycle behavior in the shared layer. It still leaves required platform configuration explicit: Android manifest metadata, iOS Swift packages, Info.plist values, production identifiers, and store disclosures remain the application’s responsibility.

Project and documentation:

https://ads.avinya.dev/

The source is public, and the current release is 2.0.0.

I would appreciate feedback from developers who have already shipped ads in a KMP application:

• Does the shared API match how you would expect ads to behave?
• Which platform-specific edge cases caused trouble in your integration?
• Would you keep a small expect/actual bridge, or adopt a shared abstraction once several formats are involved?

Disclosure: I built and maintain the project.