Does anyone has experience with the VIPER architecture pattern on iOS and Swift? Or has a more experienced example project than a simple two views app? I’m currently using MVVM-C with router. I would like to still keep the concept of the coordinates in VIPER, is it a redundancy? A bad choice? or do I missed a part?

I have looked into VIPER before and found it very excessive.

I’m working with a team atm that is using MVVM-C. Can I ask why you feel the need for coordinators? I feel like these are only being used to replace segues. Again I think there is just so much extra effort involved in using them.

My preference would be just MVVM using delegates or callbacks, and navigation in storyboards with segues

The reason why I use coordinator pattern is, that I can easily swap and modify flows. For example an registration flow, where you have something like a wizard where the user puts his information in / or an onboarding flow where are multiple screens following each other. Some random UX designer may tell you to change the order of the screen and there you go, this will take to at least few hours, with coordinations you are able to change flow in few seconds and may even run even A/B testing.

@fsoc not true. It doesn’t take several hours to delete one segue and move and create a new one to another screen. Takes all of 15 seconds.

You then have the added benefit of a storyboard where other devs can visually see the navigation without any possibility of confusion or misunderstanding.

My biggest issue right now is trying to follow the flow of screens clicking through dozens of code files instead of just opening a storyboard.

I’ve heard the UI/UX designer issue before. Never experienced it to a degree so severe that I thought segues were ill suited for the project. Is this actually happening to you right now? A lot of people I talk to use phrases like “Incase”, “possibility”, “previous company” etc. and it never seems to be an issue right now. There is a well known concept of “Death by future proofing”. If you keep adding more layers “just Incase” you will be adding code forever and it will be unmaintainable.

I don’t want to convince you, it is your decision. I think for myself that it is more convenient to use coordinations, especially if you pass data between the views. I do not use any buggy storyboards because I’m much faster with code-driven views, even I tried it once. If you have huge storyboards, even if you split those up, you may experience ugly xml merge conflicts which no one hopes to resolve, you need speak to your team who works on which storyboard to prevent any conflicts ,... coordinator pattern solved many issues in my projects with the concept of stacking view-controllers. I have experienced may cases of UX flow changes. Sure these terms sound familiar to me like “possibility” or even “incase” but I must admit that I enjoy writing and learning new approaches, especially architecture design.

Once you go bla,.. sorry, coordinators, you never go back 🤓

@fsoc lol, I can count on one hand the number of storyboard merge conflicts I’ve had to deal with. I think that’s blown way out of proportion, and comes more from bad practices rather than an issue with the tech. Team communication and knowing what each other is working on is a good thing. Adding a new layer every time there is a hiccup is not.

Working with a team that started with MVVM and then added coordinators. Then the viewModels got too big so they added interactors. Then that got to messy so we added factories, and then managers to control the lot. Every time missing the true source of the issue and making some of the worst code I’ve seen in my life.

Any technology or pattern can be abused. The key is separating personal preference, and process issues from the tech itself. Keep everything as small, simple and as few points of interaction as possible.

It’s only my advice. Feel free to ignore it.

So, whats your solution? What do you suggest in complex applications with a lot of views? Storyboards?

@fsoc the mini-storyboard approach. 1 storyboard per flow/module. Like login, home, pay a bill, account, help etc.

Segues between VC’s. Storyboard segues between modules.

And then MVVM following apples existing architectures and guidelines. Using delegates or callbacks. Have a protocol or a super class for viewModels, keep everything consistent. No need to triple the number of dependencies to add Rx to tell you when to refresh a screen.

There’s no need to fight apple reinventing wheels. Putting business logic in a viewModel so it’s more easy to unit test, and then keep everything else the same. It’s super easy to on-board new people as it’s what they are used to, but still has a massive benefit with unit tests