Crash reporting and known major crashes
All Pugpig apps come with Crashlytics integrated as part of a broader Google Firebase implementation. Other than creating your Firebase account and giving us access, nothing specific 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.
- 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.
- 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
- No known major crashes as of 3.8
- Regression causing occasional crashes when downloading editions (Fixed in 3.15.5)
- Occasional crash when opening content from a deeplink and closing it in a specific timeframe (Fixed in 3.13.13)
- Crash when deeplinking to content that isn't a valid page (Fixed in 3.12.9)
- Occasional crash when running out of memory due to puzzle usage (Fixed in 3.9)
Crashlytics and dSYMs for Bolt iOS
You may get emails to say that Crashlytics has detected a missing dSYM. These are needed for Firebase to identify some iOS crashes. There is no action for you to take as we also get this emails and will upload as and when required. If you feel you are getting them often, then please let us know by raising a support ticket (by emailing email@example.com).