Crash in background with MRAID ads



We have encountered a fully reproducible crash that is being caused by MRAID ads. The crash information can be found here:

Note that the crash is actually hitting gpus_ReturnNotPermittedKillClient, which indicates that the application is attempting to use the GPU from the background.

In testing, I have been able to track this down to MRAID creatives being the cause of this issue. What appears to be happening is that the MoPub implementation for MRAIDs does not take the application state into account. I have been able to verify that multiple “loads” of web content can easily happen after the application enters the background. Any one of these could potentially trigger a GPU request, which crashes the application.

I made an attempt to block the MRAID calls from continuing after the app entered the background, but was unable to get the fix to work. No matter what I did, it appears that the MRAID code continued to allow loading of ad content.

An update should be made to the MRAID adaptor to stop all running ad content when the application enters the background so as not to cause any crashes of the application.


We are seeing the same crash. We know the crash is coming from the MoPub SDK. We use our own mediation layer on our client and increased the % of clients that use MoPub yesterday and saw a HUGE spike in number of crashes (15x crashes).

Were you able to block the offending Ad? If so, can you let us know how you did it?


In our case, the crash has been occurring on arbitrary MRAID ads, so it wasn’t really possible to block specific ads to prevent the crash. Any MRAID creative that made use of GPU-based HTML5 can cause the ad, and slower internet connections can make it worse.

We’re still waiting to hear from MoPub about steps to fix the problem.


Hi @JoeSzymanski and @topwobble,

Thank you for reaching out about this! This has actually been escalated to our support team already by a few other publishers. Our SDK team is looking into improving the performance for MRAID creatives. It would be great to see what creative ID was creating the issue for you if you can provide it. If so, please email it to If not, our team should have enough examples to start digging into this issue. If you need any additional help, please don’t hesitate to reach out to the support team via the email provided.



Thanks @jackie. We don’t log the creative IDs. I think that Joe is correct about this being an issue that occurs when the app is in the background, as our crash logs do see a “did enter background” event.


Hi @topwobble,

Thanks for letting us know and providing us with that detail. We’ll continue to investigate this on our end. If you ever have a creative ID you an share, please email it to us at



@jackie any update on this crash? We have seen over 1/2 million crashes from MoPub.


@jackie Are there any updates here? We had a possible fix sent to us, but that did not solve the crash and caused additional other problems. We’re several limited by the fact that there is no way to target an account to only receive MRAID ads, so we can’t even get standard testing to try to fix the problem ourselves.


Hi @JoeSzymanski

Thanks for reaching out! Can you follow up with your MoPub team directly about this? They are your best resources to tackle this problem.



We finally have a workaround form MoPub that appears to be working, though with side effects.

To work around this crash, you need to add an observer to the application did enter background notification. When this notification is fired, you should remove all MPAdViews from their superviews and set them to nil to deallocate them.
When the app returns to the foreground, you can create new MPAdViews to display ads again.

We have validated that this workaround appears to remove the crash itself.

One side effect to this is that, when the user returns to the app, no ad will be displayed unit the first request completes. This could have side effects on your ad-related stats like CTR. We have not gotten any data on how much this impacts our own app yet, so anyone else will have to determine the cost versus benefits for using this workaround.