Hey @rastislv , welcome to the forums and thanks for your question!
First off, let’s go over the purpose for a concrete coordinator and router:
A concrete coordinator knows how to create view controllers and when they should be displayed. However, it doesn’t actually know how to display view controllers.
A concrete router knows how to display view controllers, but it doesn’t know which to display.
Why does “concrete” matter? Coordinators and routers are designed to work together, but they are loosely coupled! That is, a concrete coordinator will know about a router protocol object, but it won’t know what concrete router it’s actually using.
Thereby, you can easily swap whatever concrete router you’d like to use for any given concrete coordinator, such as depending on device type or even at runtime for the same device!
Just like you can create a concrete router for displaying (pushing/popping) view controllers onto a
UINavigationController, you can also create a concrete router for displaying view controllers onto a
However, when would it make sense to do this?
You can the use coordinator pattern as a generic “architectural pattern” – used throughout your app – if you’d like. In which case, you’d default to always creating a router for displaying view controllers, including on a
Although, “you can use this pattern everywhere” isn’t a really satisfying answer, is it?
In general, the coordinator pattern makes most sense whenever you need to determine at runtime whichever view controllers need to be displayed in a sequence (the responsibility of the coordinator), want to swap out how said view controllers are displayed (the responsibility of the router), and/or have a need to decouple view controllers from one another (via the coordinator), such as a very large/dynamic/complex app.
For exactly how to create coordinators and routers, I’d recommend running through the chapter again in the book about this!
I hope this answer helps you. If you have any other questions about this, please let me know. :]