Imagine you've just built an amazing iOS app for a restaurant. The client loves it, the users love it, their dogs love it, etc. As expected, soon enough you get a call from the client: Hey, can you make the same app for my other restaurant? Sounds simple. Just copy-paste…
After tackling the Single Responsibility Principle and Open-Closed Principle, it's time to explore the Liskov Substitution Principle (LSP) and how it can help us write better code. At first glance, it's straightforward: if we have a component X conforming to protocol A, and another component (Y) conforming to the same…
Over the years, we've been told to use dependency injection to help our apps scale better. On the other hand, design patterns like MV suggest simplifying app design to the minimum, often overlooking proper dependency management. While most of us instinctively understand that Dependency Injection is crucial for maintainability, testability,…
Have you ever joined a development team that was a team in name only? Torn apart by internal conflicts, petty quarrels, clashing egos, and office politics? Or perhaps you've seen a seemingly perfect candidate join a well-organized team, only to fail to integrate and quickly leave? Finding and recruiting exceptional…
The Open-Closed Principle (OCP) represents the letter "O" in S.O.L.I.D. It teaches us to create software that is open to extension but closed to change, enhancing its maintainability and scalability. To be honest, the OCP is one of the most challenging S.O.L.I.D. principles to understand and apply in iOS projects.…
What distinguishes a top 10% iOS developer? How can we draw parallels with the craftsmen of old? In what ways can we refine our skills following their lead? How should we select our projects, clients, and companies? Once involved in a project, how do we initiate change to ensure its…
How many responsibilities should a class have? As many as it needs! This is a common joke, but the reality often is far less amusing... How often do we encounter… “challenging” code annotated with "Do not change!!!" comments? Software development isn't rocket science. There are a few basic rules that most…
Imagine you’ve just implemented a nice feature. Cleanly separated UI from business logic, added some unit tests, etc. Surely, code review would be a formality. Instead, this insufferable Senior Dev requested that you wrap one of the services with abstraction. Surely, you’ve read somewhere that you should operate on abstractions…
