Good session. It would be a good session teaching good API consumption practices and teaching VIP.

Thanks for covering this! I think it’s important to mention why MVC doesn’t work so well in the world of iOS and that’s because Views and Controllers are essentially the same thing with UIViewControllers. Makes it hard to decouple Business Logic to UI and hard to cover with tests

Very clearly explained! Good use of the flowchart visuals in explaining the concepts. Question: when you explained MVP and gave the example of the View modifying the Model, that would require layout code to be combined with user interaction code right? Would that make the View more of a View Controller?

In my opinion, thinking of M, V and C as separate layers - is the main issue that leads to all problems (we may have a ModelController - it's part of the Model functionality though, we may have a TransitioningController - it's part of the View functionality though, we may have a DataSyncController - we may think of it as part of the Model or as part of the Controller layer, it has both Data and Controller in its name, lots of confusion if we try to think of each layer it would belong to and in my opinion - it should probably not have anything to do with MVC since it shouldn't be part of the UI layer at all). I like to think of the simplest 3-Layer Architecture instead (Data Access layer, Business Logic layer, and User Interface layer), and no matter if we use MVC, MVVM, MVP - they all belong to the top UI layer. The confusion most developers make is that each of M, V, and C should map with one of those layers, which is not true I'd rather think of them as camps/categories, and instead of having 3 folders/groups in Xcode, say Models, Views and Controllers... I'd rather have some Screens folder, and Models, View, and Controllers folders inside each specific screen-name folder if we wish so (it's easier to navigate a new codebase as well if done that way, no need to spend time what files from Views folder relate to what files from Controllers folder as it would be in first case scenario). I know some people say, for instance, Networking and JSON to class/struct instances conversion would be part of Model as well in MVC, which is fine (since it's related to the source of truth), but I'd rather introduce a Coordinator (even in MVC), some Utility data conversion / mapping classes, and create a separate Service Layer that would contain a lot of functionality for backend APIs interaction. We may have different modules where different teams use different architectures, and they may all use same HTTPClient or some Service instance - which would mean that these classes have really nothing to do with MVC, MVVM, MVP etc. And the problems with MVC especially start happening when we start think of those letters as Layers instead of camps/categories to start implementing separation concerns. Software became more complex over time, and if we shouldn't think each of the three "layers" of MVC is enough for us. Some objects simply don't fit into MVC, MVVM, or MVP and that's ok. Those are UI architectures / Design Patterns as already mentioned, and not App Architectures. P.S.: Also we should not confuse Business Logic with App Logic, one is a separate layer, and ultimately should reside on the server since it can change at any given time, but the app should be smart enough to adjust/replicate it locally on the fly ideally (for instance, can we have a . in the username) and the other one can be something that's done while creating the UI/View functionality which has nothing to do with the business logic, business rules etc. cause it's simply application logic (for instance, disabling the password field if username is not entered yet has nothing to do with business logic, and can be removed from the client side functionality without any changes at all on the server side... business doesn't care, and if Android app does this small change and iOS app not yet - business logic remains the same [assuming it was implemented in first place])