Conquering Chaos: How We Tamed Google Ads SDK Crash in Our iOS App

Photo by BoliviaInteligente on Unsplash

In this tech tale, we narrate our expedition of integrating the Google Ads SDK into our iOS application. Along the way, we faced sluggish performance and app crashes, but fear not 👀! We emerged victorious with clever solutions to these challenges 🥂.

The Scene: Imagine our app as a busy market where users can explore different news sections feeds. Our application has multiple feeds (list of items). More than one feed list could be in memory at a time. Every feed list can have multiple ads. Also if the user tab on any item in the feed then details of that item would get open, this detail page can also have multiple ads.

Act I: Setting the Stage Eager to monetize, we decided to integrate the Google Ads SDK. Our plan was simple: load up multiple ads at runtime on different feed and watch the revenue roll in. But as our users scrolled through the feeds, disaster struck. The app slowed to a crawl, and eventually crashed, leaving us scratching our heads 🤯. We also analysed the memory graph & memory utilisation but everything was in order.

Act II: The Unexpected Hurdles Our debugging efforts revealed a sinister culprit: a stubborn background task spawned by the Google SDK. It stubbornly refused to go away, leading to our app’s untimely demise. With no way to control it, we found ourselves trapped in a loop of crashes and frustration. We observed below errors in debug console :

• [BackgroundTask] Background Task 156 (“com.google.backgroundPing”), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.
• Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 “target is not running or doesn’t have entitlement com.apple.runningboard.assertions.webkit” UserInfo={NSLocalizedFailureReason=target is not running or doesn’t have entitlement com.apple.runningboard.assertions.webkit}>
• 0x1290b3000 — ProcessAssertion::acquireSync Failed to acquire RBS assertion ‘WebProcess NearSuspended Assertion’ for process with PID=10347, error: Error Domain=RBSServiceErrorDomain Code=1 “target is not running or doesn’t have entitlement com.apple.runningboard.assertions.webkit” UserInfo={NSLocalizedFailureReason=target is not running or doesn’t have entitlement com.apple.runningboard.assertions.webkit}

Act III: So we make this our problem statement: How to stop these background tasks? But the problem is here we don’t have the process ID to stop the task. Now we changed our problem statement to: Can we restrict multiple ads load requests? Answer was yes : A Stroke of Genius Determined to reclaim control. Instead of bombarding the SDK with ad requests as user scroll in a feed OR move to different feeds, we decided to play it smart. Enter the serial queue: with this in place, only one ad would be requested at a time, saving our app from overload.

Act IV: Overcoming Obstacles But our victory was short-lived. As users scrolled quickly, multiple ad requests flooded the queue, causing delays in rendering. To solve this, we implemented a local ad cache, ensuring that only unique ads were loaded. Also clean items from the serial queue if their request is not started and load the last added element in the queue. With this tweak, our app regained its speed and stability.

Photo by Philippe Yuan on Unsplash

Epilogue: As we bid farewell to our tech tale, we reflect on the lessons learned. Integrating the Google Ads SDK was no walk in the park, but with perseverance and dedication, we conquered its challenges. And so, our app stands stronger. Please do let me know if you need any help with code.

Hope you enjoyed this article. Thanks for reading this🙏🙏. Any feedback in the comment section would be appreciated. If you feel , please share and add some claps 👏 👏 .

Stay in the loop! Follow for fresh articles!