Crash reporting and known major crashes

We have moved to docs.pugpig.com! You can find this article here

All Pugpig apps come with Crashlytics integrated as part of a broader Google Firebase implementation. Nothing is required of you to initialise this reporting.

By default, Crashlytics produces regular emails highlighting known or new issues, and these get to sent to all accounts that have access to the Firebase project. These emails can often seem alarming, however, in most cases, you can safely ignore them for the reasons detailed below.

Firstly, we receive all of these warnings as well. These are delivered straight to our engineering team who triage them as they come in. We’ll proactively flag with you any issues that require action on your part, such as releasing a new version of your app. Minor issues will be resolved as part of our normal development flow and those fixes included in future versions of the platform.

Secondly, the threshold for Crashlytics to send one of these emails is very low. Often a transient crash on just one or two devices is enough to trigger one, particularly an issue on Android with its plethora of devices and OS combinations. Additionally, this reporting includes what are termed non-fatal incidents, in other words issues that didn’t cause a crash but some other error. Some of these are bad and need addressing quickly, such as those which cause the app to become unresponsive, while others will go totally unnoticed by users. These non-fatals can greatly inflate the number of reported issues. Again, these are dealt with as part of our triage flow, with critical ones being resolved swiftly and others being added to the roadmap for resolution in future versions.

The above should mean that you don’t need to worry about the emails you receive from Crashlytics, however, there are certain circumstances in which you should get in touch.

1. If any of these emails highlight a crash rate higher than 50 users or 2% of your user base, whichever is lower. In all likelihood we’ll already be aware of this issue, but it can never hurt to flag things of such substantial scale.
2. Numerous reports directly from your users. If an app consistently crashes too early in the startup process it won’t have the ability to communicate with Crashlytics. In these (very, very rare) cases you or your users might be the first sign we get, so flagging these early is hugely helpful.

Currently known crashes

Bolt iOS

Crash when onboarding screens and auth state don’t resolve properly (Fixed in 3.8)

Inconsistent crash when restoring state on app foreground (Fixed in 3.8)

Potential crash when interacting with content carousel (Fixed in 3.8)

Potential crash when navigating away from a timeline (Fixed in 3.8)

Bolt Android

Occasional crash when running out of memory due to puzzle usage (To be fixed in 3.9.X)

Crash when reading a feed that’s too big (Fixed in 3.8)