History
In the early days of computer programming there were no good debuggers available that helped you debug the program step by step, therefore the easiest way was to print it in the console.
Even when there were better debuggers they were not well integrated into an IDE so it was much easier just to write printf and to get the information thru the console. But once the developer has already written many printfs/logs, why not just save the console output so that the developer will always have this information when needed.
Today there are great debuggers that are fully integrated into the IDE. For example, xcode and Android Studio have great debuggers and the developer can see all the information easily through them.
So nowadays the need to trace the code is much less than before. Whenever there is a problem the developer can put a few breakpoints where needed and he can easily get all the information. The developer can step in the code wherever needed.
In the server world even though the logs are needed less for the development it is part of the methodology that each developer learns to work with. And when there are problems in staging or production they will analyze the logs in order to understand what happened.
Logs in development stage
There is no question that Android (Android Studio) and iOS (Xcode) IDEs are advanced so there is less need to write logs for development. With breakpoints you can stop where needed and get all the information of the current state of the program.
Problems with debuggers:
-
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.
-
Logs give the developer 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 them 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.
Logging in mobile app development
There is a big difference between iOS and Android developers
iOS
In iOS there is ‘NSLog’ and ‘print.’ *
NSLog:
- Works in objective-c and swift programming language.
- Statements appear in both the device's console and debuggers’ console.
- NSLog also adds timestamps and identifiers to the output.
- NSLog is slower than print.
Print:
- Works only in swift programming language
- Appears only in debuggers’ console.
- Print is faster than NSLog
Xcode debugger console is very basic. Once you have many logs it is difficult to find what you need, you can’t filter it, the only thing that you can do is search according to strings.
Therefor most iOS developers prefer there to 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 they’ll 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. It works in java and kotlin programming language. 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 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.
Log management solution
In order to use app logs in production you need to have a logging platform that stores the logs in the cloud.
Without this there is no way for the developer to see the logs remotely. There are several logging solutions but most of them do not specialized in mobile apps.
It is important to choose the right logging platform, that is specifically for mobile apps, to integrate into the app.
Conclusion
There is no doubt that a good developer should use all the tools that are available for him. In modern times we have two great tools that work together and do not contradict each other.
For the production stage the only solution that exists for the moment is logging. You can’t remotely debug a phone app of a real customer. Therefore it is important to integrate a log management solution into the app, that will help the developer fix the issues in production.
--
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.
* From iOS 10 there is a new system that is os log. In addition to NSLog, 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. These