Is Crash Reporting Enough?
In the mobile app development world it is very common to use Crash Reporting Tools. But it is much less common to use Log Management Tools.
Developers view a crash in the app as a top priority that has to be fixed.
There is no doubt that a crash in the app is very disturbing for the user experience of the app. But, it isn’t the only thing that disturbs the user experience.
In this article we will describe the importance of using a Log Management Tool that uploads the logs to the cloud in addition to having a Crash Reporting tool.
Understanding the source of the crash
One of the problems that happens is that you find the location of the crash but don’t know why it happened. For example: a null (In iOS it is called nil, but due to the fact that in most languages it is null I will call it null in this article) pointer that calls a function/member. The problem is that it is often not clear how it came to be in that state. If you also had the logs then it would be much easier to find the source of the issue. You could see the code that was run just before the crash and caused the crash.
Sometimes my crashes have even been in the iOS infrastructure. The infrastructure started running from a different thread. I didn’t have any way of knowing what brought about this crash. The only way to find it in this case is to look what happened in the app before this occurred and try to see what could have triggered the crash, and this can only be done with app logs.
Swift and Kotlin aim to be Null safe languages
Swift and Kotlin aim to eliminate the danger of null references from code, also known as “The Billion Dollar Mistake” *.
They both distinguish between references that can hold null (nullable references) and those that can not (non-null references).
In the case where they can hold null, they force the developer to check whether it is null.
Therefore in Android and iOS there are less null exceptions than in the past. It doesn’t mean that the code is better and that the end user has a good experience.
The problem is that once the developer checks for the null exception, he will usually just ensure that the code doesn’t continue. That will cause a big disturbance for the end user because he won’t get what he is supposed to.
The null safety just throws the problem somewhere else and makes sure that the app won’t crash but it doesn’t solve the problem.
If there isn’t a log in that kind of case, that the developer can see, he won’t know that there was a serious problem in the app.
Issue detection with error logs
Error severity logs should show that there was a major problem that needs to be dealt with.
For example: If there is an error in parsing a json from a rest api. The code won’t be able to continue. By having a log it will be possible to discover that there was a major problem with the server.
By having error logs the developer is able to detect issues in the code before the user complains about them.
To be able to use the log efficiently it is very important to have the logs severity correctly assigned. If there are too many logs that get the level “error” then they won’t be able to know if there is a problem. If there are too few logs or no logging then there won’t be the information that is needed.
Conclusion
Due to the fact that Log Management and Crash Reporting work hand in hand both are important for the quality of the app.
Log Management tools should have Crash Reporting in them. Without it, they are missing basic functionality that can’t always be overcome even if also using a Crash Reporting service. For example: analyzing a crash and understanding how it came about. Knowing only where the crash happened isn’t always enough.
It is very important to have a logging system that uploads the logs to the cloud and lets the developer view them remotely.
--
Shipbook gives you the power to remotely gather, search and analyze your user mobile app logs and exceptions in the cloud, on a per-user & session basis.
*https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions