Mobile app crashes can happen when the app is in the foreground or in the background. However, we currently do not surface this detail to the developer.

Currently, we surface a stack trace value was active to developers (image above) but this can manifest differently depending on the framework:

1. Single Thread frameworks (Flutter, React Native) - will be true regardless of the app being in foreground or background
2. Multi-thread frameworks (Android, iOS) - will be at individual thread level and reflects state for that thread

For scenario 1, was active is not an accurate proxy for whether the app was in foreground/ background at crash time and this new value app.in_foreground aims to address this problem. While for scenario 2, was active can be a more accurate proxy.

Surfacing app.in_foreground raises a scoping question: Do we want to surface this as a tag?
It has already be made searchable in the Issue stream and we see value in being able to break metrics down by this value.

Additional notes:

• Front-end task for exposing the new app context coming in Add new app context that tells if the app is in the background or foreground team-mobile#36

• Related PR: Make app.in_foreground searchable #43964