RORK LABJP
TOOLING — Rork's developer repos keep moving: rork-xcode was updated on July 16, rork-device on July 15, and rork-plist on July 13OPUS46 — Claude Opus 4.6 is live in Rork, and Rork Max is built to assemble apps on top of Claude CodeSIM — A cloud iOS simulator runs in the browser, with one click to install on a device and two clicks to publish to the App StoreMAX — Rork Max emits pure Swift rather than React Native, reaching iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and even iMessageNATIVE — That opens up HealthKit, ARKit and LiDAR, NFC, Dynamic Island, Live Activities, 3D through Metal, and on-device inference with Core MLSEED — Rork raised a $15M seed led by Left Lane Capital, with Peak XV and a16z Speedrun joining the roundTOOLING — Rork's developer repos keep moving: rork-xcode was updated on July 16, rork-device on July 15, and rork-plist on July 13OPUS46 — Claude Opus 4.6 is live in Rork, and Rork Max is built to assemble apps on top of Claude CodeSIM — A cloud iOS simulator runs in the browser, with one click to install on a device and two clicks to publish to the App StoreMAX — Rork Max emits pure Swift rather than React Native, reaching iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and even iMessageNATIVE — That opens up HealthKit, ARKit and LiDAR, NFC, Dynamic Island, Live Activities, 3D through Metal, and on-device inference with Core MLSEED — Rork raised a $15M seed led by Left Lane Capital, with Peak XV and a16z Speedrun joining the round
Articles/Dev Tools
Dev Tools/2026-05-19Advanced

Auto-Throttling AdMob When Crash Rates Spike: A Revenue-Protecting Brake Architecture with Rork, Firebase Remote Config, and Crashlytics

When crash rates spike, do you keep showing ads and watch your store rating crater, or pull back and accept the lost revenue? After 12 years of indie operations, my answer is neither: a four-state auto-throttle architecture that ties Firebase Remote Config and Crashlytics signals into AdMob serving decisions.

Rork515AdMob70Firebase Remote Config2Crashlytics12Architecture17Long-term Operations3Indie Developer11

Premium Article

In spring 2024, one of the wallpaper apps I run watched its crash rate jump from 0.3% to 4.8% within hours of a minor iOS 18 update. The technical culprit turned out to be a CADisplayLink behavior change, but the part I regret most is something else: for the twelve hours it took me to notice, my app kept happily serving AdMob interstitials. Twenty-seven reviews piled up saying "it crashes the moment an ad appears." The average rating dropped from 4.5 to 4.1, and over the following weeks organic installs fell 32%. The ad revenue I earned during those twelve hours was dwarfed many times over by what I lost afterward.

I'm Masaki Hirokawa, an artist-creator who has been building personal apps since 2014. My catalog has crossed 50 million cumulative downloads, and once AdMob revenue passed the threshold of seven figures (in Japanese yen) per month, I started treating revenue and stability as something that belongs on the same dashboard. This article walks through the four-layer architecture I now use to detect rising crash rates and automatically dial back AdMob serving — and, just as importantly, how to dial it back up safely.

Why Tie Ads and Stability into a Single Architecture

The Google Mobile Ads SDK initialization is heavier on the process startup path than most documentation suggests. From AdMob SDK v11 onwards, parallel initialization and cold-start improvements have helped, but in my measurements the AdMob-related class loading still accounts for 8 to 14 percent of cold-start time, and once you layer mediation SDKs (AppLovin, Meta Audience Network, and so on) it can exceed 20 percent. When a crash spike hits, you don't just have an app problem; you potentially have ad-SDK-driven crashes (WebKit process OOM, mediation bid-request cascades) muddying the diagnostic signal.

Wiring "if crash rate exceeds X, throttle ad serving in stages" into the runtime gives you three things at once. First, it physically stops the bleeding. Second, it removes ad-SDK-related crashes from the Crashlytics noise floor while you triage. Third — and this is the one that compounds — it prevents users from establishing the association "ads here mean crashes." That association persists in reviews for years.

Architectural Overview — Four Layers with Distinct Responsibilities

The system breaks cleanly into four layers, each independently safe-failable.

  1. Observation layer: Firebase Crashlytics plus custom telemetry, collecting crash and error signals in real time
  2. Decision layer: Cloud Functions (or Cloudflare Workers) aggregating the data into three rolling windows and choosing a state
  3. Distribution layer: Firebase Remote Config delivering the chosen ad_throttle_state to clients
  4. Execution layer: A client-side AdServingGate that translates state into actual load/show decisions

The layering matters most when you're recovering from an incident at 3 a.m. The last-resort safety nets are: manually rewrite Remote Config to Normal, then the distribution kill switch, then the client fallback default. Each layer can fail safe on its own. Knowing that lets you sleep.

State Model: Normal, Caution, Throttle, Halt

In my production apps, the four states are tuned as follows:

  • Normal: Crash-free rate ≥ 99.7%. All ad units serve normally.
  • Caution: Crash-free rate between 99.0% and 99.69%. Interstitial frequency cut to 50%; rewarded ads continue.
  • Throttle: Crash-free rate between 96.0% and 98.99%. Interstitials disabled; banners only; rewarded ads served only on explicit user action.
  • Halt: Crash-free rate below 96.0%, or more than 20 crashes per minute. All ad loading stops; SDK initialization is skipped.

The four-state granularity is what lets you preserve revenue even when the system misfires. In one of my apps, a 6-hour Throttle held revenue at 24% of normal during that window — but the upstream Caution period kept revenue at 72% of normal before things deteriorated. The all-or-nothing version of this system would have run me to zero.

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
Three-tier rolling-window monitoring (1-minute / 10-minute / 60-minute) with concrete thresholds that suppress false triggers
A four-state phase-out (Normal / Caution / Throttle / Halt) delivered through Firebase Remote Config, with full implementation code
A recovery playbook covering hysteresis, smoke tests, and manual overrides — preserving 72% of AdMob revenue while restoring stability
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.

or
Unlock all articles with Membership →
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.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

Dev Tools2026-05-21
Automating Production Incident Response as a Solo Developer — Crashlytics, Sentry, Slack Routing, and Staged Rollback
Twelve years of running my own iPhone and Android apps, accumulating 50 million downloads, taught me a specific shape for production incident response. This article shares the Crashlytics + Sentry double layer, Slack routing into interrupt and log channels, and a Remote Config plus EAS Update staged rollback I keep returning to.
Dev Tools2026-05-31
Running Crash-Free Rate as a Budget: An SLO Design Note for Deciding Where to Invest Across 6 Indie Apps
Notes from running 6 wallpaper apps in parallel and the shift from treating crash-free rate as a pass/fail threshold to treating it as an error budget. A working write-up on turning burn rate into investment and sunset decisions.
Dev Tools2026-05-27
Making Silent Failures Visible Across 6 Rork Apps: An Early-Warning Design Note for Non-Crash Degradation
Notes from running 6 wallpaper apps in parallel and the layer I built in 3 weeks to make Crashlytics-invisible failures observable. Beacons, timeouts, and a small Cloudflare Worker for cross-app aggregation.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →