MVVM vs VIP, which one is the best?

The debate between MVVM and VIP architectures is ongoing, but the truth is that neither is a one-size-fits-all solution. Architectures cannot universally fit all codebases, as code evolves and requirements change. Instead, the focus should be on respecting boundaries within the codebase.

For greenfield projects, starting with MVVM might be a good idea. MVVM is simple to begin with, many developers are familiar with it, and it works well with SwiftUI's state-driven model. However, choosing an architecture based solely on its name isn't a reliable strategy. A ViewModel can still become a catch-all for network, persistence, and business logic if proper design principles aren't followed.

For instance, look at a poorly designed LoginInteractor class. It directly handles network requests and other infrastructure details, making the code harder to isolate, replace, and test. In contrast, an Interactor that depends on abstractions, like a LoginWorker protocol, allows for easier testing by mocking the worker component. This approach keeps the codebase more maintainable and adaptable to changes.

The key takeaway is not the architecture name itself, but rather whether the boundaries are respected. The ideal structure is: Presentation (UI) -> Application/Use Case -> Domain -> Data Infrastructure. This structure ensures that the UI doesn't dictate how data is fetched, business rules aren't tied to specific data sources, and infrastructure doesn't dictate application behavior.

By maintaining clear boundaries, developers can better understand how to structure their code as it grows in complexity, without worrying about unrelated code being affected by changes to a single feature.