Crashes report in iOS life cycle metrics

[#1]

Hi,

I have a question regarding Crashes report in iOS life cycle metrics. 
Can someone please explain how 'Crashes' report is tracked in SiteCatalyst?

"Triggered when the application does not exit gracefully. Event is sent on application start after crash (the application is considered to crash if quit is not called)."

We found the above in documentation, but we need more details. 

What is a quit and when is it called/triggers usually?

The reason why I'm asking is because we are seeing a massive increase in our crashes report since we launched our latest app version. But the new version traffic seems to be doing better than our previous versions.
The numbers we are seeing from SiteCatalyst aren’t the same we are seeing from Crittercism (10k vs 150k daily) – we’d like to understand what triggers the instance.
We don't have any idea why SiteCatalyst suddenly reports such an increase in Crashes report. 

Thanks

[#2 · Accepted solution]

First I'll tackle how we track crashing.  As the documentation states, when the app doesn't "exit gracefully", we send a crash on the next launch.  By exiting gracefully, all we mean is entering the backgrounded state (receiving the applicationDidEnterBackground notification from the OS) prior to the app closing.  Any time the user pushes the home button on their iOS device, the current app will be backgrounded (this includes pressing the button twice to pull up the app switcher for multitasking purposes).

There are couple common reasons why your SiteCatalyst data may be reporting higher number than Crashlytics or Crittercism:

1. When the app is re-launched from the iOS Simulator while it is already running, the subsequent launch is reported as a crash.  This is because the app never gets background, Xcode terminates it while it is still the active app.
2. Crashes due to running out of memory.  Crashlytics and Crittercism have to create their own objects to report your crashes, and they can't do that when your app is out of memory.  From our perspective, all we know is that the app exited when it was considered the foreground app, so the next launch is considered a crash.

Hope this helps.

steve benedick
mobile software engineer
Adobe Marketing Cloud   

[#3]

Hey Mike,

Sending hits when the app enters the background (or while the app is in the background) can cause issues in your lifecycle data.  If you are sending hits via the SDK from the background, make sure you're using the trackActionFromBackground:data: message.  Using this will suppress new lifecycle sessions from being created by your app's activity while it's in the background.

If this doesn't help, I recommend contacting Client Care so we can get a ticket open for you.  

steve benedick
mobile software engineer
Adobe Marketing Cloud

[#4]

I would like to know the same. We are seeing very high crash rates for iOS - above 50% - but don't see the same data from Crashlytics. Our Android crash rates are below 5%.

[#5]

Steve - I'm also seeing a lot of extra visits with no page views. These visits typically include a launch, crash, and no activity time. For any particular user and device these can happen several times per day, and on multiple days. 

How can I figure out what activities are occurring that are causing the launch/crash/visit to report but no other activity?

It happens much more often in iOS than Android.

-Mike.