The art of eliminating when solving bugs.
An effective way of solving bugs in iOS developing.
Bugs. Every software developer will have to face them sooner or later, some of them will be easy to solve others not so much, some might make you loose your mind others will make you feel like this industry was waiting only for you Sherlock. In some rare cases a portion of the app needs to be re-written just to overcome an unwanted bug.
If bugs are such a big thing than how come no one is teaching us how to solve them, or better how to face them? in most cases thats the developers code that behaves exactly as they wrote it, but not as they intend. One might think that the more experience you get the less bugs you're likely to write, but the truth is that the more experience you get the more complex your code gets thus finding the source of the bugs becomes a time consuming job.
I faced some nasty bugs, data racing, core data inconsistency, reference cycles, you name it. Sometimes the bug crashed my app and there wasn't even a stack trace and sometimes the app didn’t crash but something wasn’t working properly. I was on my own, playing guessing games , with no useable stack trace I couldn’t even google it.
🤷🏻♂️ What do you do when:
- There is no crash log, or lacking meaningful hints.
- The bug is inconsistent.
- The app does not crash but simply wont behave the way you wrote it.
- Everything seems ok but nothing works.
The answer is simple: I put on my Sherlock Holmes goggles and start “Eliminating” possible suspects. Sometimes the best way to understand what causing a bug is to understand whats not causing it. What? 🤯
As the title says solving bugs is an art, some bugs are strait forward others require some thinking, not how to solve them but what causing them.
🤔 What skill will you achieve by the end of this article ?
Will you solve any possible bug? probably not, but thats not the point . Instead I’m going to “rewire” your brains concept of bugs, hopefully you will be able the identify the cause faster with these steps.
First step: Understand what you're dealing with.
- ⛔️ Optional unwrapping failed.
- ⛔️ UI different then intended.
- ⛔️ Memory Issues.
- ⛔️ Data racing.
- ⛔️ etc…
Second Step: Understand what you do know vs what you don’t.
Suppose we have a UI issue, we have a UILabel with some text that we want to show, for some reason the label isn’t shown when the app runs. I wont provide any context of how the view hierarchy is built, although the experienced developers might come up with the fix quickly I want focus on the way of solving, not the solution.
Following the chart I provided:
Ask your self questions about the situation, what can cause this type of behaviour, I wouldn't advice to start coding a solution right away, firstly understand why this is happening, once you figured it out located the root of the problem. Avoid using pointed patches even when time is tight in most cases bugs can be solved by a few simple changes.
Since this is a UI issue lets open our “View Hierarchy Debugger”:
🤨 What do we do know for sure?
- The app does not crash therefore its probably not a broken @IBOutlet.
- The view hierarchy shows the the label is not hidden, and the alpha set to 1.0, which means that it's not a game of hide and seek.
- The label is part of the view hierarchies, which means the label was added properly to the view.
- The background colour did set and the text is correct, the label’s background is pink so no-one is assigning it clear by accident, same for the text its correct and coloured white. Which hints to us that no-one is messing with label properties, yet we cant see the label.
By this point we can assume it not a “UILabel” problem. Moving on.
5. The Label is a subview of “View” (the white view in the middle) How does this help us? What do we know about views?
- A view has a frame and bounds one represents its location in its parent view, the other its location relative to it self. Which hints to us that maybe the label position has exceeded the parent visible area. If the “Clip To Bounds” checkbox was selected then we wouldn’t see the label in our storyboard, but we do see it.
- Views often have some sort of constraints, which hints to us that maybe this is a constraint issue.
When looking on our label’s “Frame” we can see that the label positioned correctly in the X axis but the Y axis is 150 extra from the parent Y point.
Next we see that one of the constraint causing it, “self.top = superview.top + 150 @ 1000”, obviously the constraint is causing the problem right? Yes…, but why cant we see the label?. Remember we don’t have context about this project we don't know why the developer chose the behaviour of assigning 150+superview.top might not be a bug but a request, the bug as we know it is that we can’t see the label at all.
👩🏻💻 Third Step: Fix it or search it
Views have a property named “clipToBounds” which means that everything beyond the view’s frame will be clipped and not visible.
The thing is if we see the label in our storyboard then we should see it when the app runs, make an assumption that someone is messing with this properties in the code,
If you are correct, locate the exact line and reason, make the necessary changes and VIOLA, problem solved. Otherwise, keep digging.
If you ever seen a “Sherlock Holmes” episode you know that even though he is a great detective and can solve any crime, he always needs someone to ask him questions, the better your questions the more likely you will solve the problem sooner then later, thats a promise.
It might sound like a sentence taken from an inspirational film, but I always say:
“If your stuck your not asking the right questions” — Alex.P
I would love to hear what you guys think about solving bugs and if this article changed the way you address bugs, even by a bit.
