●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SDK 58 — Expo SDK 58 is out of beta as of 10/15 (beta since 09/15). Check your dependencies before upgrading●WIDGET — A write-up traces an iOS widget that renders black only in production builds●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SDK 58 — Expo SDK 58 is out of beta as of 10/15 (beta since 09/15). Check your dependencies before upgrading●WIDGET — A write-up traces an iOS widget that renders black only in production builds●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…
Expanding AdMob bidding demand without adding SDKs — what applying to 11 server-side partners taught me about 'enabled ≠ serving'
A working log of actually adding SDK-free, server-side bidding partners to AdMob's bidding sources: the difference between doc-type and form-type sign-up flows, how reCAPTCHA behaves, and the trap that 'partnership enabled' does not mean 'eligible to serve', told from a solo developer's point of view.
"I want more bidding sources. But I do not want to add a single new SDK." That seemingly contradictory requirement is what kicked off a recent session of applying to every server-side bidding partner AdMob would let me. The punchline: understanding the boundary — that getting a partner enabled does not, by itself, add a single impression — turned out to matter far more than the applications themselves.
I have been building smartphone apps solo since 2014, mostly wallpaper, relaxation, and law-of-attraction titles, with roughly 50 million cumulative downloads and AdMob revenue that peaked above one million yen per month. The thing that has burned me repeatedly in that operation is the number of ad SDKs. Every mediation adapter I add to the Android build inflates the AAB, and one version shipped a crash that took down every Android 6.0.1 user — a Glide 5.0.5 plus AGP 9 interaction (one line, coreLibraryDesugaringEnabled true, fixed it, but I lost half a day finding it). An SDK brings demand, yes — and it reliably increases your maintenance and crash surface too.
That is exactly why "if I could add only the demand sources that bid, without adding SDKs, that would be ideal" becomes the goal. AdMob's bidding sources include a slot built for precisely this: SDK-free, server-side bidding partners. This time I applied to 11 of them, and I want to record what went as expected, what tripped me up, and what I ultimately adopted — along with the reasoning for each call.
Why "apply to a bidding partner" rather than "add another waterfall"
For context: on my Android apps (Beautiful Wallpapers net.dolice.beautifulwallpapers and Ukiyo-e Wallpapers net.dolice.ukiyoe), the Unity Ads waterfall mediation I had relied on for years is structurally dead. Google AdMob officially announced that "Unity Ads waterfall mediation support ends January 31, 2026," and the reports bear it out: about 97,000 requests over seven days returning 0 impressions and $0.00 revenue, stable and reproducible across three consecutive weekly snapshots. There is no point adding more waterfall lines.
If I want new demand, there are two paths.
One is integrating a bidding-capable ad network together with its SDK. Demand can be strong, but it brings a whole bundle along: adapter Pods or Gradle dependencies, app-ads.txt lines, and behavior checks on test devices. The other — the subject of this article — is a server-side bidding partner that bids purely through AdMob's server-to-server connection without putting any SDK into the app. The latter never touches the app binary, so its maintenance and crash risk is close to zero. For someone running a deliberate SDK-reduction policy, the sensible order is: max out the server-side partners first, then promote to SDK integration only the ones that truly justify it.
There are two sign-up flow types — doc-type and form-type
As you enable partners from the AdMob console under "Mediation → Bidding → Set up ad source," you notice the sign-up flow splits into two broad patterns. Knowing which one you are in lets you predict how long each partner will take.
Doc-type: pressing "Steps to sign the partnership agreement" in AdMob opens a Google help document, and step 1 is auto-completed. You just return to AdMob and press step 2, "Review and agree," to enable it. The actual partner relationship is established offline. Of the ones I tried, Improve Digital (Azerion) and Mobfox were this type. Done in minutes.
Form-type: "Sign the partnership agreement" → "View and sign" sends you out to the partner's external site, where you fill in a form, agree to terms, and submit. Then you return to AdMob and press step 2, "Review and agree." Chocolate Platform, Nativo, Verve Group, Sharethrough, and Yieldmo were this type. A publisher ID like pub-0667784050147760 is carried over automatically from Google, so you do not need to type it into the form.
Form-type has one practical trap: whether you can automate it depends on the kind of reCAPTCHA. Sites using reCAPTCHA v3 (the invisible kind), like Verve, pass on scoring alone at submit time, so you can sail through. Sites that show reCAPTCHA v2 (the checkbox kind), like Sharethrough, physically require a human to tick the box — that step alone cannot be automated and has to be clicked by hand. I delegate most of this operational legwork to an AI assistant, but the v2 checkbox is one thing I clear myself every time.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦The flow for adding SDK-free partners to AdMob bidding sources (doc-type vs form-type, and how reCAPTCHA behaves)
✦Why 'partnership enabled' and 'eligible to serve' are different things, and how to spot partners that secretly require an adapter SDK
✦Concrete criteria for what to adopt and what to skip among 11 partners under a strict no-new-SDK policy
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
The result of 11 applications — enabled, submitted, ineligible
The outcome split cleanly into three tiers.
Verve Group reached full activation. It passed reCAPTCHA v3 automatically, the form submitted successfully including an address field, and AdMob's step 2 is agreed.
Enabled via the offline, doc-type flow: Improve Digital and Mobfox. Step 2 in AdMob is agreed for both.
Form submitted but awaiting the partner's processing: Chocolate Platform (states they will contact within 24 hours), Nativo (two business days, an existing Outbrain relationship may be a prerequisite), Sharethrough, and Yieldmo. For these questionnaire-style partners, AdMob's step 2 only opens once the partner clears their review.
And four that could not even start — "ineligible." Nexxen returned "Email already exists," needing an existing-account check; Rise requires a corporate entity (Ltd. / Inc.), so as a sole proprietor I am out; MobileFuse and Sonobi are US/Canada only, a regional mismatch from the start. MobileFuse additionally had a scale requirement of one million requests per day.
The lesson for solo developers is clear: server-side bidding partners are not "anyone can apply." There are three gates — corporate entity, region, and minimum traffic — and if you are a sole proprietor based in Asia, the set of partners you can actually apply to is far narrower than you would expect. Skimming each partner's eligibility before you start saves wasted trips.
The biggest trap — "partnership enabled" does not mean "eligible to serve"
This is the part I most wanted to write down.
I had initially classified BidMachine, LY Ads Network, and most likely DT Exchange as "SDK-free server-side bidding" among the partners AdMob shows as "partnership active." That was wrong. These actually require integrating each partner's adapter SDK into the app, and the "partnership active" label in AdMob means only that the account contract is complete — not that you are eligible to serve. They are in the same "SDK-required" group as Moloco.
So bidding partners fall into two fundamentally different kinds.
First, pure server-side bidding, like the 11 I applied to this time. AdMob's servers talk directly to the partner's servers, so nothing touches the app binary. Enabled equals serving (once app-ads.txt is in place).
Second, partners where enabling appears to complete on the server side, but actual serving requires an adapter SDK. BidMachine / LY Ads / DT Exchange are here. In the AdMob console they can be "enabled" just like the first kind, so if you assume "it must be serving by now," you will burn time unable to explain why impressions never rise.
The way to tell them apart is simple: check first whether the partner's AdMob integration guide mentions an "adapter," "Gradle dependency," "Pod," or "SDK version." If it does, that partner is SDK-required. Use "does the integration guide list adapter coordinates?" as your criterion, not "it enabled, so it should serve," and you avoid this entire misunderstanding.
Under a no-new-SDK policy, what I adopted and what I skipped
Back to the contradictory requirement from the opening: more demand, no more SDKs. Hold that line, and the decisions make themselves.
The 11 pure server-side partners: adopt all of them, since none adds an SDK. As approvals land, I append each partner's seller line to app-ads.txt.
The three SDK-required partners: skip by default. With one exception. I decided to adopt LY Ads Network alone, as an Android-only pilot, targeting Japanese demand. My apps' user base is heavily Japanese, and LY (formerly LINE Yahoo) demand is unlikely to be fully captured by other global ad networks. BidMachine and DT Exchange I skipped, because right now I see no demand unique enough to justify the cost of one more SDK.
Not "the demand is fat, so add everything," but "does this demand uniquely outweigh the cost of one more SDK?" That is the criterion I arrived at after twelve years of solo development repeatedly suffering from SDK bloat. In the same spirit as stopping AppLovin, Unity, and Mintegral, I treat an SDK not as something to add but as something that must continuously justify its slot.
The LY Ads pilot implementation steps (Android, BW / UKI)
LY Ads, which I decided to adopt, will ship in an upcoming Android update. Here is a reproducible record of how to add exactly one SDK-required partner.
First, check the adapter's Gradle coordinates, whether the SDK must be bundled, and the credentials, in AdMob's LY Ads integration guide. Then add the adapter dependency to the app's app/build.gradle.
Once the adapter is in, do not rewrite the ProGuard / R8 and AAB checks from scratch — reuse the verification script from the InMobi integration (verify-inmobi-build.sh). The thing that tends to break after adding an adapter is an R8-obfuscation-induced NoClassDefFoundError that only happens in release builds, so it is safest to run all the way through ./gradlew bundleRelease and confirm a real ad renders on a device. If you judge "debug build is fine," it will first break in production.
With that done, add the LY Ads bidding source to the relevant AdMob mediation groups (INT, and BNR if needed). Finally confirm whether an app-ads.txt line is required, and after release, monitor crash rate and imp / eCPM for one to two weeks. The trick to a pilot is to decide the retreat line up front: roll out to other apps if clean, pull it if not.
app-ads.txt comes "after approval" — never fabricate a seller ID
There is one thing to observe strictly for pure server-side partners. Each is designed to hand you its own seller ID (the authorized-seller line) after approval, so you must not write the line yourself beforehand.
# After approval, append the lines each partner specifies to dolice.net/app-ads.txt# Example (domains are known, but wait for each partner's ID — below is a format illustration)verve.com, <ID specified by partner>, RESELLER, 0c8f5958fc2d6270improvedigital.com, <ID specified by partner>, RESELLERsharethrough.com, <ID specified by partner>, RESELLER
A common mistake is to fill in a guessed seller ID just because you know the domain. app-ads.txt declares "who is authorized to sell my inventory on this domain," so a fabricated ID can, in the worst case, leave that line's demand unauthorized and invalid. I standardized on transcribing each partner's specified DIRECT / RESELLER line verbatim only after I receive the approval email. Since it sits behind Cloudflare's cache, do not forget to purge after appending.
Criteria for a solo developer adding server-side bidding partners
To close, here is the whole exercise on one page. If you are about to grow your bidding demand, checking in this order should waste the least time.
First, confirm via the integration guide whether the demand source you want is pure server-side bidding or adapter-SDK-required. Next, before applying, confirm whether you meet the eligibility on corporate entity, region, and minimum traffic. For SDK-required partners, decide adoption purely on "does this demand uniquely outweigh the cost of one more SDK?" And write app-ads.txt only after approval, transcribing each partner's specified line verbatim.
For my part, I broadened pure server-side bidding in every direction, while limiting the SDK-required slot to a single Japan-demand pilot with LY Ads. Growing demand and keeping a maintainable state are often a trade-off. Consciously choosing that trade-off, every time, is itself the operational discipline that lets a solo developer keep an ad business running for the long haul.
Start by applying to just one pure server-side bidding partner in your own mediation group. Once you feel what it is like to add a unit of demand without touching the app binary, the line at which you should commit to an SDK integration becomes clear on its own.
Share
Thank You for Reading
Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.