●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 — Beta since 09/15 with no stable date yet; running projects in Expo Go has required login since 09/03●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 — Beta since 09/15 with no stable date yet; running projects in Expo Go has required login since 09/03●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…
The Day I Walked Away From $730/Month — Pulling AppLovin From 5 Apps After 11 Years of Crash Data
On 2026-05-26 I paused AppLovin and AppLovinMax Bidding + Waterfall across my entire iOS/Android catalogue (50M+ cumulative downloads) for INT, RWD, and RWI. This is the full record of the three lines of evidence I used to justify walking away from $730/month and the four-week evaluation framework I set up afterwards.
On the afternoon of May 26 I opened AdMob's mediation dashboard and paused every AppLovin and AppLovinMax bidding and waterfall source across all five of my iOS and Android apps, for INT, RWD, and RWI. About $730 a month of revenue stops flowing.
I am Masaki Hirokawa, an indie developer since 2014 with around 50 million cumulative downloads across the catalogue. AppLovin had been embedded in my main apps since 2022 and was one of the SDKs that supported a 1M JPY/month AdMob revenue era. This article walks through the three lines of evidence that led to the cut and the four-week evaluation framework that comes next.
If you run monetisation across multiple networks, hesitate between user attrition and revenue, see user feedback about "unclosable ads" or "rewards never granted" and aren't sure how to interpret it, or you want to systematise the rules for cutting a network — this is for you.
The three lines of evidence I needed to walk away from $730/month
A "give up the money" decision can't be made on instinct alone. I needed three independent lines of evidence. No single one would have justified the cut; all three together did.
Evidence 1 — Anomalous ad-quality numbers from AppDiscovery
AppLovin has two dashboards. Publishers normally only look at AppLovin MAX (where you serve ads in your own app). The other one — AppDiscovery — runs the advertiser side, where your apps' ads run inside other apps. Most devs never see it. I only found it mid-investigation.
The last 30 days of AppDiscovery delivery (2026-04-27 to 05-26):
The row that caught me: Beautiful 4K/HDR Wallpapers (Android). CTR 13.04% × RPC $0.0092 × eCPM $1.21.
Healthy ad-delivery ranges are CTR 2–5% and RPC (revenue per click) $0.10–$0.50. CTR 13% is 2.5x–6x the healthy range. RPC $0.0092 is 1/10–1/50 of healthy. "Lots of clicks, zero installs, micro-revenue" is the textbook pattern for mis-tap / misleading-click creatives.
AppLovin Network bills on installs. When clicks don't convert to installs, the chain never monetises. CTR-anomalously-high paired with RPC-anomalously-low is exactly what "unclosable ads → mis-taps → no install" looks like as a UX problem.
Evidence 2 — Direct user observation
I ran the AppLovin RWD (rewarded video) ad in test mode inside my own app. After the video finished, the only available action was "click," and the reward wasn't granted.
A rewarded video opt-in carries two assumed safeties:
Watching to completion guarantees a reward
A clear "close" path exists after watching
Both broken. RWD is worse than INT here.
INT "can't close": the user grumbles and closes it eventually. Mild irritation
RWD "no reward": the user paid time with no return. Contract-violation-level distrust
When a user actively opted in ("I'll watch a video for the reward") and got this, the chance they ever watch another RWD or keep the app drops sharply.
Evidence 3 — The 11-year crash trend
This is what closed the case. App Store Connect Analytics shows monthly crash counts across an app's full history back to 2015. I opened the chart for all five of my main apps at the 11-year window.
Every single app shows a clean spike in 2022 — the exact period AppLovin was integrated. BW 4K/HDR jumps 8x, others 2.5–3.5x. And the trend never fully returned to baseline; it stayed chronically elevated at 2–3x.
Three things to notice:
The temporal pattern is shared across 5 apps — that excludes app-specific bugs, because the codebases are different and wouldn't all hit the same shape simultaneously
Sudden spike, not gradual deterioration — that excludes environment changes (OS updates, device generation turnover) as explanations
Chronic elevation — not a one-off SDK bug. Structural
This isn't a correlation you can hand-wave as coincidence.
The branch point: "fix and wait" vs. "cut"
When you see signals that users are leaving, you've got two choices:
A: Wait for SDK fixes / work around it from app-side code
B: Cut the SDK
I normally try A first. With InMobi or Liftoff issues over the years, I waited for SDK updates or lowered mediation priority. Why B this time? Because the three lines of evidence together pointed at a structural problem, not an individual defect.
Three independent dimensions, each independently anomalous. That's the kind of pattern that doesn't resolve from one more SDK release.
While you sit in "fix and wait" mode, you're watching users silently churn for the sake of a few hundred dollars a month. I'd been in that mode for six months. The hardest lesson from this episode: notice faster, act faster.
✦
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
✦How to build the case for cutting a $700+/month media partner using CTR/RPC anomalies, an 11-year crash trend, and direct user observation — three independent lines of evidence that no single data point would justify
✦How to read an AppDiscovery row that looks like CTR 13% × RPC $0.0092 × eCPM $1.21 against the healthy CTR 2–5% / RPC $0.10–$0.50 range to confirm a 'high-click low-conversion' creative quality failure
✦A four-week post-stop evaluation matrix with branching outcomes (permanent / partial restore / emergency restore) and the caveats you need when a hotfix release lands the day after the stop
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.
"Full stop" is shorthand. The actual stop was INT + RWD + RWI. AOA (App Open Ad) and BNR (Banner) stayed untouched at first. The reasoning:
INT — the source of "unclosable" UX complaints and CTR 13% anomaly. Stop confirmed
RWD — direct observation of "no reward." Stop confirmed
RWI — same AppLovin demand as RWD, same risk. Stop confirmed
AOA — AppLovin doesn't even support AOA waterfall. AdMob doesn't list it. Nothing to stop
BNR — no "close" concept, no UX loss. Different click dynamics
Later in the day, I stopped BNR too. Two reasons: (a) possible non-zero crash contribution, (b) clean experimental signal. If I'm going to measure crash-rate improvement across four weeks, fewer AppLovin paths means easier causal attribution. BNR revenue was already small, so the cost was minimal. Cleaner experiment design won.
Operationally: AdMob → Mediation → for each group's Bidding sources and Waterfall sources, change the AppLovin / AppLovinMax row's status to Pause (not Delete). Pause keeps the original eCPM / config in place, so if the four-week verdict is "restore," nothing has to be rebuilt.
The four-week evaluation framework
The decision isn't done with the pause. Four weeks from now I run an evaluation. Axes in priority order:
Crash rate change (top priority) — Firebase Crashlytics + Play Console Vitals + App Store Connect Crashes. Pass condition: crash-free user rate up by 0.3pt or more, or a clear drop in ad-SDK-attributed issue count
Retention change — D1 / D7 / D30 compared four weeks pre-stop versus four weeks post-stop. Pass condition: +1pt or more
Qualitative review change — review counts containing "ad," "reward," "crash," "freeze," and the equivalents in Japanese ("広告," "閉じ," "報酬," "うざい," "落ちる")
Revenue impact — total revenue, network share shifts
Click-level monetisation efficiency — overall INT CTR / RPC / eCPM before vs. after
Decision matrix:
Crash rate improves + retention improves + loss tolerable → permanent stop. Consider full AppLovin Adapter SDK removal
Crash rate improves only (retention flat) → continue stop. Crash reduction alone is worth the $700/month
Retention improves + crash flat → keep monitoring. Different AppLovin factor (UX); leave the Adapter installed for surveillance
Retention flat + revenue loss → partial restore. Bring back only the older BW iOS (largest single-source)
Crash rate worsens → emergency restore. Roll everything back immediately and re-investigate
The major caveat: BW v2.1.1 / UE v1.8.1 hotfixes ship the day after the stop (2026-05-27). Any crash-rate improvement could be from either AppLovin removal or the release. I have to separate the two.
Concretely: known bugs the release fixed (BW-017 ViewPager2 fling IOOBE at 74.4% of v2.1.0 crashes, BW-027 Glide synchronous-decode ANR) are subtracted from "AppLovin effect." In Firebase Crashlytics, filter for issues whose path contains applovin and track those separately. That subset is the AppLovin signal.
Day 1 — eCPM dropped 33% and the "don't panic" call
Observation from the stop day (2026-05-26):
AdMob overall eCPM: $1.81 → $1.20 (down about 33%)
Other networks (Meta, AdMob Network, Liftoff, Mintegral) need 3–5 days to relearn against the new auction landscape
One-day data is noisy; conclusions are premature
Removing one bidder shrinks auction competition, so a short-term eCPM dip is expected. Meta and AdMob Network optimisation takes a few days to fill the vacated slots. Changing anything during that window destroys the experiment signal. I fixed the stance: observe for 3–5 days, no further changes.
I made one supporting tweak in AdMob settings:
Share full IP address: off → on (expect +5–15% eCPM)
Programmatic restricted ads: on → on (held) — counter-intuitively, off cuts revenue
The second item is a trap. Reading the description carefully reveals it covers "Google demand, certified buyers, and SDK bidding demand," so turning it off shrinks the demand pool. Reading SaaS-product settings descriptions in full is one of those unglamorous monetisation fundamentals.
Revised loss expectation
The older BW iOS (Beautiful HD Wallpapers 20,000+, App ID 632379876) is the largest single revenue source at $618/month, but I excluded it from the stop. Reasons: it's a much older binary on a different user cohort, and including it would muddy the experiment signal for the four-app comparison.
Revised loss expectations:
Original estimate (with older BW): $730/month, $170/week, $683/4-weeks
Updated estimate (without older BW): about $111/month, about $26/week, about $104/4-weeks
A hundred-and-change a month is a bearable loss even if the four-week verdict shows no crash improvement. On the upside, if crash-free user rate moves +0.3pt, the user-side impact against a 50M-download portfolio is much larger. The risk/reward became clean enough to push Pause without flinching.
Minimum steps for an indie dev to replicate this
If another indie wants to apply the same logic to AppLovin (or any other network) on their own catalogue:
Check both Publisher and Advertiser dashboards for the network (for AppLovin: MAX and AppDiscovery)
Compare CTR / RPC / eCPM against healthy ranges (CTR 2–5%, RPC $0.10–$0.50). Flag any anomaly
Run user observation: play the ad in test mode inside your own app and feel the UX
Open App Store Connect Analytics and pull monthly crash trends across the full app history. Look for spikes at the SDK integration timestamp
If three independent lines of evidence each show anomalies, decide to stop
Decompose the stop scope by format (INT / RWD / RWI / AOA / BNR). For cleaner experiment signal, stop BNR too
Lock the evaluation matrix (crash / retention / review / revenue / click efficiency) before pulling the trigger
Plan for any release that lands during the evaluation window — use issue-level filters in Crashlytics to separate the AppLovin signal from the release signal
A "walk away from revenue" decision can't be made on data alone or on instinct alone. The two ingredients are three intersecting independent lines of evidence and an evaluation framework locked in before the stop. With both in hand, hitting Pause on $730/month becomes possible.
Both of my grandfathers were temple carpenters, and I grew up around the idea that not everything is yours to repair. SDKs sit on the same axis. Waiting indefinitely for someone else to fix what's broken becomes harmful at some point. This stop is me trying to draw that line for myself. Whatever the verdict at the four-week mark, the reasoning is now on disk; the next time another network exhibits the same pattern, I should move faster.
Thanks for reading.
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.