Hi, i just ended chapter with coordinator and I am a little bit confused with differences between coordinators and routers. Also, when I am using UITabBarController should I initiate in appdelegaterouter or create it as coordinator?
My last question is about variable “children” in coordinator protocol - I am not sure for which scenario I should use it.
thank you for my dummy questions
@jrg.developer Can you please help with this when you get a chance? Thank you - much appreciated! :]
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 UITabBarController.
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 UITabBarController.
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. :]
Hey, please help me out with this as well … I myself is looking for the answer to it for a long time… Thankyou so much
It would be great to have some code example using router and coordinator for UITabbarcontroller. 
@jrg.developer
@jrg.developer Do you have any feedback about this? Thank you - much appreciated! :]
Thanks for your feedback. :]
We’ll consider this for this next edition of the book. See my comments above regarding general advice for how you might do this, though.
Basically, though – The main difference is the concrete router, which needs to know about the UITabBarController and how to display controllers on it, and the concrete coordinator, which needs to know to provide several controllers to its router upfront.
Good luck!
– Joshua