Intro
In the software development world, when developers want to understand why something doesn’t work in the program that they developed, the first place to look is the logs. The logs give the developer a “behind the scene” view of what happened to the code when the program ran.
The question is why, in mobile app development, developers aren’t using the app logs to analyze app issues. Some even remove them before production, for example, in Android they use ״proguard״ to remove the logs.
Significance of Logs
Before we start explaining the reasons why mobile app developers don’t use logs, let’s examine the importance of logs.
The significance of logs is divided between the development stage and the deployment (QA/staging/production) stage.
Development Stage
In the development world, there are two contradicting philosophies:
-
Use logs for everything - Whenever you want to know what is happening with the code just add a log. And you’ll be able to easily see the whole flow of what happened.
-
Use a debugger for everything - The debugger gives much more information than the logs. Logs also use resources.
The truth lies usually somewhere in the middle.
There is no question that modern IDEs have great debuggers. The need to trace the code is much less than before. With breakpoints you can stop where needed and get all the information of the current state of the program.
The problem with the debugger is that you can only go forward, you can’t see things before the place that you are debugging. You can rerun the whole program. But many times, it is faster to look at the logs and see what exactly happened.
With logs you can get an overview from where the problem is. Sometimes you don’t know where to start looking. In this case, it is much easier to add a few logs and with it to find the location of the issue in the code. After you find the location then you can continue debugging with a debugger.
In cases of multi-threading it can sometimes be a nightmare to use a debugger. You can’t step in the new thread because it isn’t the next step. Sometimes the flow of the program even changes because you’re debugging.
Deployment (QA/Staging/Production) Stage
In the deployment stage, unlike the development stage, there is no real alternative to using logs.
Whenever there is an issue that happened during the deployment, the only way to know what really happened is the logs. With it you can see what the code did when the issue happened.
It also shows the developer that there is an issue. If you get an error/warning you need to see why it happened. You don’t always notice that there is an issue, but the logs show you that there was a problem that needs to be dealt with.
The level of the logs is also important. Having the log level in this stage from warning and up, will maybe show you when there is an issue but won’t help you analyze the source of the issue. Therefore, there should be means of easily changing the configuration to be able to balance between the cost of resources and the need to get information to analyze issues.
Reasons Why Mobile App Developers Don’t Use Logs
There are two main reasons why mobile app developers aren’t using logs.
- The DNA of modern app developers.
- Missing adequate logging platforms.
The DNA of Modern Mobile App Developers
Mobile development is a relatively complex subject. Developers that were developing servers didn’t go into mobile development. Most mobile developers started with mobile development as their first job. Most apps were not even developed in the companies internally, but by software service companies.
These developers didn’t have the methodology and knowledge that are common in the rest of the software development world.
Due to the fact that the Android (Android Studio) and iOS (Xcode) IDEs are advanced there is less of a need to write logs for development. The problem starts once the app is in production and problems surface. Then there is no way to analyze them.
Missing Adequate Logging Platforms
iOS
By default, you’ve in iOS ‘NSLog’ and ‘print.’ NSLog statements appear in both the device's console and debuggers’ console whereas print only shows the information in the debugger console. NSLog also adds timestamps and identifiers to the output. For these reasons, NSLog is slower than print.
From iOS 10 there is a new system that is os log. Like NSLog, it adds the timestamp and identifier and appears in both the device's console and debuggers’ console. In addition, you can now control the "subsystem" and "category" fields available in the Console app. And you can specify different types of logging messages like .info, .debug, .error, and .fault.
In any case the xcode debugger console is very basic. Once you have many logs it is difficult to find what you need, there is no filtering, the only thing that you can do is search according to strings.
This is why many iOS developers prefer that there be no log. And only in the case where they are working on a specific section will they add the logs to help to debug and then delete them.
The biggest problem is that when the app goes on another device there is no way for the iOS developer to see these logs remotely.
Android
In Android, you have android.util.log by default. This lets the developer log in a decent way and when developing in Android Studio the developer has the logcat that gives a relatively good solution for the development stage. You can search in it with regex and according to log severities.
Therefore, most Android developers will write logs.
The biggest problem is similar to iOS. Once the app goes on another device there is no way for the Android developer to see these logs remotely. Therefore, some developers use “proguard” to remove all the logs so that they won’t use phone resources if in any case not used
What Should a Logging Platform for Mobile Have?
Like we saw, the default iOS and Android logs are far from what we need. They don’t even have the basics of being able to see the logs remotely or uploading them to a place where you can look at them.
So, what are the capabilities that a logging platform for mobile should have?
-
Logs as a service/cloud: The logs should be uploaded to the cloud where it is possible for developers to look at them whenever they want. Systems that only send the information when the customer complaints, are not sufficient, due to the fact that you can’t see issues without the users actively complaining.
-
Session and user-based logging: The information should be saved according to sessions and devices. It doesn’t help that all the messages are in a server, but you can’t see the full flow of the session or of the user.
-
Log analysis capabilities: There should be the possibility to view and search according to log severity, OS version, app version, device type, app state, etc.
-
Log Remote Configuration: Ability to remotely close and open logs according to the current needs. It should be possible to configure according to severity and categories (tags) which logs are open and closed.
-
Log Monitoring and Alerts: Should be able to monitor on a high level view the state of the app according to the logs, and automatically send an alert when the system monitors problems. The alert system should be automatic. Developers shouldn’t create alerts according to how they understand it, so that they won’t miss things that they didn’t expect.
-
Crash Report and Log Management: It is important to have these two tools in one place/together. A crash report isn’t complete without the logs that happened before. There are many crashes where you can see the line in the code that brought the crash but still don’t understand how you got to this situation.
-- Shipbook gives you the power to remotely gather, search and analyze your user logs and exceptions in the cloud, on a per-user & session basis