Crash or OOM: See What’s Really Happening

At Embrace, we can demonstrate whether an app experiences memory leaking by observing the chance of an OOM occurring at different intervals of time from when the app emerges from the “cold” state (when the app isn’t running in the foreground or background).  For an app which doesn’t have memory leaking, the chance of an OOM occurring isn’t associated with the time since a cold start.  Shorter times are just as likely to OOM as longer times.  But for apps which have memory leaking, the chance of an OOM gets higher the longer the app has been utilized.

We can visually show this.  In the graph below, the x-axis represents 15 second interval buckets — 1 on the axis represents sessions which have ended 0-15 seconds after the most recent cold start of the app, 2 represents 15-30 seconds, all the way up to 40 which signifies sessions which have ended 9 min 45 seconds – 10 minutes after the last cold start.  The y-axis represents the proportion of sessions in each 15-second interval bucket that has ended in an OOM.  All three graphed lines represent real apps that Embrace measures, but the two solid lines are apps that have issues handling memory, whereas the dashed line app does not:

All 3 apps start off okay, but by the time we reach the 10-minute mark, about 10-15% of sessions are ending in an OOM for the memory leaking apps, whereas the normal dashed line app has maintained roughly a 2-3% OOM rate the entire time.

In order to sprint, you need to clear the path.  Embrace helps companies achieve visibility into what’s getting in their users’ way.

OOMs: 5 Times More Common than Crashes

Mobile apps crash.  It’s a fact of life, and it’s feared by all.

But what a lot of app companies don’t realize is that crashes make up a very small percentage of their total app traffic.  For the iOS apps that Embrace measures, the average app has just 0.07% of sessions ending in a crash.

At first glance, that number doesn’t make sense.  You’ve had apps crash on you all the time– how are you always in that 0.07%?  The reality is that what you are seeing is most likely not a crash, but what we refer in the industry as an OOM.

OOMs stand for “Out of Memory” but signify any instance where an app suddenly closes and doesn’t have time to send over a stack trace for why the app closed. In general, OOMs occur when the device’s operating system (OS) decides to reclaim memory for other processes.  When the OS does this, it terminates the app to free up RAM.

OOMs aren’t technically crashes because no stack trace is sent, but make no mistake — these OOMs look and feel exactly like crashes to the user.  And just like crashes, OOMs create poor customer experiences and increase customer churn.


Group of people lined up looking at their mobile phones.

What sets OOMs apart from crashes is that OOMs are much more common.  OOMs are roughly 5 times more common than crashes.  To have your developer teams hunt down crashes and not OOMs is akin to trying to dodge lightning while not looking both ways when crossing the street.  Of course, crashes are easier to find and fix, but going through life only watching out for lightning has never been a great strategy.

Developers can create better apps when they achieve visibility into user sessions. Based on those insights, developers know what is getting in users way, which makes it possible for developers to make necessary changes that result in amazing apps that create great user experiences. Take it for a test drive today.

If you found a few bits of value, please share:
Release Notes: An Overlooked Tool In Your Mobile App Development
What Really Causes OOMs?

Leave a Reply

Your email address will not be published. Required fields are marked *