Debugging iOS apps with DBDebugToolkit
“We’re a bit overwhelmed by the number of builds we get from our CI. We install a lot of them, and after a while we are not quite sure which version we currently have installed on our device. Could you add the version and build numbers somewhere in the app?”
I will always remember the moment at nomtek when one of our testers told me about this problem. It was at the beginning of a big project, so I knew that solving it quickly would help them a lot in the future. Of course it’s not a big deal and there are a lot of ways to achieve that: you could add it to one of the screens after consulting your designer, add it to the Settings Bundle or even to the app icon. Temporarily we added it to one of the labels on the Home Screen of our app.
However, before doing that, I asked one question that made all the difference: “How do our friends from the Android team solve this problem?”. It turned out that they were using a library that gives them an easy access to a lot of debugging tools. You simply swipe left on your screen to present a menu.
I really liked that idea. I immediately started searching for an existing library that would help to achieve something similar on iOS. To my surprise, I failed to find anything quite like it. I was always fascinated by open source. At the time I was waiting for an idea that would feel worth spending the free time on, so I was very excited and motivated to start working on my own library. When I came back home, I opened an empty document and started writing down all the features that I would like to see there. Many long evenings and nights later, I released the first version of DBDebugToolkit.
My goal was to provide as many useful features as possible, while keeping the setup process hassle-free. This article will examine three common problems reoccuring in iOS development that DBDebugToolkit can help you with.
Working with servers
Nowadays, the vast majority of applications relies on data provided by servers. It is often the case that the core business logic is performed remotely, yet it can sometimes be neglected in tests, partly due to the asynchronous nature of the backend API calls. Moreover, if the server side is developed at the same time as your app, you should be prepared for some initial problems.
DBDebugToolkit provides the list of all the HTTP requests performed by your application, even those that have not received the response yet. You can see the duration, HTTP code and even a thumbnail if the response contains an image. The list can also be filtered to include only the requests with a specified substring in the URL.
Every request can be thoroughly examined. You can see all the HTTP headers and body details. The body details screen supports both texts and images. If the request ends with an error, you will see all the details as well.
As someone that uses DBDebugToolkit a lot, I think the requests list is one of the most useful features. It gave me a closer look at the crucial, yet hidden part of the apps, saved time needed for checking the backend API documentation and even helped to notice trivial problems such as requests being sent twice.
There are a lot of tools that can show you the requests sent by your app, e.g. Charles Proxy. What makes network debugging with DBDebugToolkit unique is the fact that it is always enabled. You will surely appreciate it when you finally reproduce the bug you were so worried about and realize that all the requests were already logged for you, even if you don’t have the debugger attached or your proxy enabled.
Moreover, DBDebugToolkit can help you verify what exactly happens with the data once it is fetched from the server. It allows you to browse files, keychain, UserDefaults, cookies and even Core Data.
Validating layout
Another situation related with DBDebugToolkit that I will always remember was when Michał, our designer, asked me if I could help him with my library. Design review is often a part of the development process, especially when you strive for the pixel perfection. However, doing it on iOS can be more troublesome than on Android, where you can use a separate app to draw a grid on top of your app and see if everything is aligned correctly. Sandboxing on iOS makes it impossible to achieve. Instead, the code responsible for drawing the grid can be injected to your app with DBDebugToolkit. I must admit that I felt ashamed that at first I was only thinking about developers and testers, not realizing that the iOS environment can be harsh for designers as well. Kudos to Michał for thinking outside the (sand)box!
DBDebugToolkit allows you to draw a highly customizable grid overlay on top of your app. You can specify the size, opacity and color of the overlay to fit the margins and color scheme of your app.
The grid overlay will help you a lot during the development and design review of your app. The story behind it is a perfect example of one of my favorite aspects of open source — it evolves according to the needs of its users.
Apart from the grid overlay, there is one more feature included in DBDebugToolkit that can be helpful during design review. There is a powerful debugging tool called UIDebuggingInformationOverlay. Among many other features, it allows you to measure views and even compare the implementation with the design.
UIDebuggingInformationOverlay is hidden in the private API, and DBDebugToolkit performs the calls needed to show it. To learn more about it, I encourage you to check out Ryan Peterson’s article. Enabling it was described thoroughly here by Derek Selander.
Feature flags
Feature flag (also known as feature toggle) is a powerful technique with a lot of applications. You can use them as an alternative to keeping separate feature branches, for canary releases or A/B tests. Essentially, they are simply variables used inside conditional statements.
DBDebugToolkit provides a mechanism called Custom Variables. It allows you to define variables, that can be modified at runtime in the debugging menu. It is perfect for using and testing feature flags.
Let’s suppose that you are thinking about simplifying the sign-up process in your application. You are not sure yet how it will affect the conversion rate, so you decide to perform an A/B test. Your code has to support both options, and you would like to have a way to switch between them in the debug builds. You can achieve that by defining and adding a custom variable:
let simplifiedSignUp = DBCustomVariable(name: "Simplified Sign-up",
value: false)
DBDebugToolkit.add(simplifiedSignUp)After executing this code, open the menu and select Custom Variables. You can see a boolean variable with a switch allowing you to modify its value:
You can check the value of the variable to determine which version of the sign-up process should be used:
guard let simplifiedSignUp = DBDebugToolkit.customVariable(withName: "Simplified Sign-up")?.value as? Bool else { return }if simplifiedSignUp {
// Open the simplified version of the sign-up process.
} else {
// Open the standard version of the sign-up process.
}
And that’s it! You can now easily test both versions of your sign-up process.
This feature allows you to define number and string variables as well. It gives you a lot of possibilities, for example you can modify the layout or the server address at runtime.
These are just examples of how DBDebugToolkit can improve your everyday work. I strongly encourage you to take a look at the full list of features.
The goal was to help the iOS community as much as possible. You can support this cause by contributing to this open source project, or simply by giving your feedback or requesting a new feature.
Any thoughts? Share them in the comments below!
