I think that’s where your own intuition and experience comes into play. You decide to add a new feature for your personal app, or get a story from your product owner at work, and are then thinking: “What do I have to do?”
Let’s assume you have to add a new tab to your application that reads data from a web service, and presents it in a collection view of custom cells.
This is where B, and your experience, come in. Right there you can probably break it down into needed a custom cell (view), an object for parsing data from the network (model), and your new controller that will host the collection view and run things (controller).
You may have very often heard clients say “I want an app that does this, this, and that!”. It’s not just the entire app was just thought of from the ground up as “MVC”, it’s further breaking down the whole “My app needs to do this” into components, chunks of work, and then going with whatever makes sense.
In essence if you follow a pattern like MVC or MVVM, you adhere to those constructs/conventions from the beginning. In the case of MVC you always aim to keep your model agnostic from your views and controllers, your views completely unaware of any models or business logic, and your controller just to run things without it becoming the model or the view layer.
It takes a bit of practice, but in my experience MVC is usually one of the cleanest patterns that’s simpler to wrap your head around. Another cool thing is Apple’s APIs are built around this as is sample code and documentation (for the most part).
If you have any further Qs, let me know I’m still not getting notified about this topic but will do my best to keep an eye out
Thanks for your questions and time,