To use or not to use Xcode’s Interface Builder (let’s call it IB) is a very common discussion between iOS developers. There are many arguments against using it like version control issues and difficulties in debugging. This post in our blog have some considerations about it for example. But I believe that if the project is well structured and the team knows how to use it, these issues can be avoided and IB can become a very powerful tool.
If you are familiar with iOS trending topics, you certainly already know VIPER. It’s an alternative to MVC (Model View Controller) pattern and it was already explained in our blog. If you haven’t read yet, I strongly recommend you to do it.
There is a lot of content on the web talking about the VIPER miracles and how this new architecture is much better than the previous ones. But you always have to ask some questions before putting your efforts and resources into an “unknown path”.
On this article, I will clarify some questions about the VIPER workflow and if you should be using it on a new project – or even on your old running app.
When I started as an iOS developer, my biggest problem was with app crashes, that’s because I really didn’t know how iOS, Swift, and Objective-C worked. Back then, I wrote a lot of bad code, not worrying about memory usage, memory access, ARC or GCD. That’s simply because I didn’t know about that stuff. I was a beginner, for God sakes.
Like most beginners, Stack Overflow community taught me a lot about “doing things the right way”. I’ve learned a lot of tricks that helped me improve my work process. In this article, I’ll share some of them about the most important tool used in this learning process: the breakpoints!