Clean iOS Architecture pt.5: MVC, MVVM, and MVP (UI Design Patterns)

[@captainmichaelj2321]

Took me a long time to understand what he was talking about here, but now I really appreciate it.

[@giuseppemorana7168]

Thanks, I think this is one of the clearest tutorials on the web which explains these patterns and how are applied to the iOS platform. Really liked to see how the original MVC is different from the Apple implementation and how all those patterns are very similar between them :)

[@EssentialDeveloper]

Thanks, Giuseppe! Glad to know you enjoyed and learned from our content. ✅⛩

[@guindows]

The best explanation ever. Direct, talking not only about the views, but included the other parts of the application as well (networking, parsing routing...), which most of other videos don't even mention about it, and very good and clear graphics. Well done mate. Thank you.

[@EssentialDeveloper]

Thank you!

[@irjayjay]

Thank you, so many crappy tutorials out there that are poorly written or recorded. Yours was the best!

[@watchit387]

yeah tell me about it, I don't know why everyone started thinking that they can teach

[@swiftandtips]

Wow, your explanation of those three patterns is amazing! Thank you so much! 👏🏼

[@rosey182]

I thank you for your clear and simple explanation. Grrrrreat job! Not a second wasted on fluff just the good stuff!

[@MrVipulLal]

Great stuff, mate. Clear , concise and comprehensive! Kudos

[@EssentialDeveloper]

Glad you liked it!

[@mnesvat]

One of the best and cleanest explanation thanks

[@abdallashawkyabdo2721]

perfect explanation, especially you mentioned the problem of MVC from the beginning of its evolution :)

[@EssentialDeveloper]

Thanks! Glad you liked it 🙂

[@Maw0822]

Best tutorial on this topic I have found by far

[@EssentialDeveloper]

Thank you!

[@nazirjama6331]

thanks, man this helped me a lot

[@EssentialDeveloper]

Glad to hear it!

[@quickfingers5982]

This is really great. Do you have an example of this, with all the layers you have (networking, routing, parsing, rendering..)?

[@EssentialDeveloper]

Hi! Yes, we cover all of those in the iOS Lead Essentials program: academy.essentialdeveloper.com - I also recommend this series on KZbin www.essentialdeveloper.com/professional-ios-engineering-series

[@kampolovna]

very nice and concise explanation, thank you for the video!

[@kitegames3351]

Great , awesome presentation

[@AmanKumar-hr5dc]

Very nice video!!!!!!!!!!!! At last, I finally understood these design patterns and the difference between MVC and MVVM clearly!!!!!! Thank you so much!!!!!!!!

[@EssentialDeveloper]

Hi Aman Singh, thanks for the feedback! We're thrilled to know you've learned with our content. ✅ Happy coding! ⛩

[@mohamednidhalmrad1228]

thanks a lot. it's very nice video. can you please explain the other design pattern clean swift and VIPER?

[@EssentialDeveloper]

Hi Mohamed, watch parts 6 and 7 in this playlist: kzbin.info/www/bejne/eZzcnaWcgNuZZ6M

[@mohamednidhalmrad1228]

Thanks 😊 you are awesome 😎

[@xaviercp2200]

the best explanation ever

[@EssentialDeveloper]

Thanks! Glad to know you enjoyed and learned from the content ✅

[@xaviercp2200]

Just a little question. WPF was designed under MVVM or MVP ??

[@EssentialDeveloper]

You can use both. The XAML binder makes MVVM more convenient.

[@osucaru009]

You have a new subscriber dude

[@EssentialDeveloper]

Welcome on board!

[@HashemRC]

I'm wondering why after one year I'm finding your tutorials and website?! great content and descriptions.

[@EssentialDeveloper]

Thank you and welcome to the channel! ✅

[@HINDISE_ENGLISHTAK]

Thanks for the video, As you explain MVC, MVP MVVM and VIPER are UI Design Pattern then what is Arachtechtural Pattern in iOS?

[@EssentialDeveloper]

Those are considered UI architectural design patterns, but they're not software architectures. Software Architecture is something else. Keep watching the series to learn more ✅

[@lifethreesixtydegree]

business logic is good to have with a model in the case of MVVM? isn't should be with viewModel? Eg. Showing a specific date format based business requirement totally should be calculated by ViewModel not by the model. correct me if I am wrong.

[@EssentialDeveloper]

Date format is *presentation* logic. We recommend you to keep presentation logic in the Presentation Layer along with ViewModels, Presenters, etc. Business models should ideally be in a higher-level module that doesn't depend on specific presentation/UI logic. ✅

[@americanaccounts]

@@EssentialDeveloper Maybe it depends or not? When I have a specific date/distance/money format for my whole project then I would create extensions for the models. Then it is encapsulated and in the model. When I need some specific presentation logic for one view, I always would put presentation logic into the viewmodels, presenters, etc.

[@EssentialDeveloper]

Hello! We recommend you to separate business models from presentation models. So you can develop, maintain, extend, and test them in isolation. You will also be able to present the same Model differently, without complex/nested if-else logic. And decouple the UI from business models. The thing is: UI/Presentation logic and business logic often change for different reasons and by different stakeholders. So, separating them gives you more flexibility to change one module without affecting the other. This doesn't mean you need to duplicate code. You can reuse the presentation logic when appropriate. ✅

[@devarajn5910]

Great video to understand these patterns, thank you. Can we have PDF document with each of these design pattern's diagrams? For those who are looking for diagrams, check video on timings below.(Alert: but make sure you go through video, Since all these patterns doesn't concern about database operation, networking etc. they can be put in Model or Controller based on your convenience ) MVC : 7:43 MVVM: 9:54 MVP : 12:19 MVC, MVVM with UIKit : 13:32 MVP with UIKit : 14:20

[@EssentialDeveloper]

Thank you! You can find the diagrams at www.essentialdeveloper.com/articles/clean-ios-architecture-pt-5-mvc-mvvm-and-mvp-ui-design-patterns ✅⛩

[@devarajn5910]

@@EssentialDeveloper thank you :) appreciate it.

[@FunnyRoom]

Good explanation, thank you

[@EssentialDeveloper]

Glad it was helpful!

[@Tobool]

Hello, thanks for this new video. One comment that I think should be added is to explain why people keep implementing MVVM though it looks like MVC+boilerplate - because VM doesn’t depend on UIKit and it is easier to test.

[@EssentialDeveloper]

Hi Piotr, thanks for sharing this! The Presenter in the MVP design pattern also doesn't depend on UIKit and can be tested in isolation. ✅

[@Korupt0]

hi. Great video. thank you. please can you tell me what software you used to create your diagrams?

[@EssentialDeveloper]

Thank you! It's draw.io

[@flytoo8055]

@@EssentialDeveloper thanks!

[@raulsilvamx]

Hi! I'm asking to all... What is the name app to make those workflow mockups? Looks amazing I would use it.

[@EssentialDeveloper]

Hi! We use draw.io

[@Felip38rito]

Hey Caio, thank you for all the tips. I was stuck in MVC (apple) and no matter how I was separating things, one layer was always doing too much as you've said. Now I'll have another paths to go :) Thanks mate. (PS: Você é brasileiro? Deu pra sentir pelo sotaque... Um abraço cara! :D)

[@EssentialDeveloper]

Hi Felipe, glad it was helpful! Yes, I'm Brazilian 🇧🇷

[@Omfe6]

oh wow All this time I though you were Italian LOL@@EssentialDeveloper

[@isurujn]

Hi, I have seen MVP tutorials where some offload things like showing an alert over to the presenter. And in some tutorials, they advice against that practice and recommend keeping the presenter UI-agnostic and have it only handle business logic. I know there is no silver bullet, 100% correct way to these things. But personally, what do you think is the better approach? Should the presenter have UI code in it or not?

[@EssentialDeveloper]

Hi Isuru! We prefer to make the presenter UI-agnostic if possible. This way, it's easier to use it in different UIs, frameworks, platforms, or apps. It's also easier to test it without the UI. Moreover, business logic ideally goes in a business domain layer. The presenter performs only presentation logic, such as formatting dates, numbers, etc. ✅

[@isurujn]

@@EssentialDeveloper Gotcha! Thank you for the explanation and the prompt reply 🙏🏼

[@CrackedRecords]

So at the end MMVM is not solving anything that wasn't "working" on MVC just moved around, and as always the best scape is "you decide where you put it"

[@wayneosaur]

So the controller didn't disappear when going from MVC to MVVM ... it's duties are just passed off to the the view and viewmodel? The controller orchestrates the interaction between view and model -- what is doing this orchestration in MVVM?

[@EssentialDeveloper]

Hi! MVVM is based on the Observer pattern, where ViewModels expose Observable properties that can be connected with the Views directly (the observers are usually done through simple closures or popular frameworks like Combine/RxSwift). With Observable properties, once the ViewModel state changes, the Views can be updated immediately and directly without an intermediary. The same on the other direction: when there's input from the User through the Views, it can also be passed to the ViewModels directly without an intermediary based on bindings. Frameworks like SwiftUI bind View and State automatically and seamlessly without the need for a Controller. When following MVVM in SwiftUI, the ViewModel can be the View State, so they are kept in sync automatically without a controller. But in UIKit, there's no automatic binding of the View and its State, so you could use the Controller as a place to bind the View with a ViewModel, for example.

[@PavelPalancica]

I recommend watching "A Better MVC" by Dave Delong, an engineer that used to work on UIKit at Apple, and another talk "MVC is not your problem" by an engineer named Joachim Kurz. Sometimes responsibilities couild be mixed. We can even have controllers in the Model layer... for instance NotesController that loads some notes to be futher used to the ViewModel, and also to temporarily keep in memory the old and new text for a note in Editing Mode. One approach that few people talk about is that UIViewController is acting more like a view than a controller, therefore should belong to the View camp (instead of Controller). So we think of it that way - the Controller object was never really present in MVC, MVVM or MVP. Imo the Coordinator from the Coordinator Pattern is actually the Controller we'd need most fo the times to implement proper MVC. Think of it as the Controller or the CoordinatingController. It has direct refernces both on Views/ViewConrollers/ViewModel and Models. And View layer objects (mostly View Controllers) would still directly access Model directly (which is basically classic MVC). I don't understand why people are so concerned with Networking or Database Access not fitting in one of those categories in Model, View, ViewModel, Controller, or Presenter. All these UI architectures are more like minimum recommended layers or categories of classes etc. to organize our code into. It's a "phylosophy" so to say, and not a strict template to follow. If our app starts with local caching or storage - later add a folder named PersitanceLayer. If we need Networking - add a Networking or Web APIs folder. That doesn't mean MVC was not good enough and now we invented MVC+S, MVC+N or MVC+NS etc. And in many cases MVVM would not necessarily solve any problem we had with MVC (if View Models are lighweight structs - you could rename them to View Data and it's just some intermediary structures, and it's still same old MVC). And MVC is not the reason why we get huge VC files. It's programmer's fault for giving too much responsibiliities to VCs. Similarly we could give too much respnsibilities to VMs. Some people even make VMs dependent on UIKit, or add the Networking code directly in VMs, which is another bad practice. Model, as per MVC phylosophy - is the ultimate source of truth. I see the objects doing the Database Access or Networking - as helpers to bring the "truth" data from the server and keep it locally temporarily. From this perspective - those two belong to the Model (even though physically they belong to a different folder or module), so there should be no doubt that it should go to the Model or the Controller. I think the main idea we could get from all this UI design patterns - is Separation of Concerns. Over-obsessing over any of them is not really worth it. There are some amazing apps out there, written in MVC, and there are some awful apps, with huge codebases, but written in MVVM and VIPER.

[@amrzayed4545]

what is the best in ios MVVM or MVP?

[@EssentialDeveloper]

Hey, we don't believe one is better than the other. MVVM is more popular than MVP in the iOS community, so it can be easier to find content about MVVM. However, we recommend you to learn both so you can choose the appropriate pattern to solve different problems. Happy coding! ✅⛩

[@americanaccounts]

Thank you very much. I would be interested how SwiftUI influences the selection of a UI pattern. In my option Apple released with SwiftUI a MVVM solution. So, in the next two years iOS 13 definitely is the default version on every iPhone. Therefore MVVM will be the new MVC. Would do you think?

[@EssentialDeveloper]

MVVM works well with SwiftUI, due to the built-in bindings. It works fine with other patterns too. ✅

[@EssentialDeveloper]

Hello! We meant State, StateObject, ObservedObject, etc.

[@EssentialDeveloper]

We teach it in the complete iOS Lead Essentials program. Check it out: iosacademy.essentialdeveloper.com/p/ios-lead-essentials/

[@EssentialDeveloper]

Hello. You don't need to follow the cohort schedule - it's optional. You can go through the program at your own pace.

[@doug8171]

Could you add some example simple but representative public github example projects for these various architectures so we can connect the diagrams to what it looks like in code?

[@EssentialDeveloper]

Hi Doug, thanks for the suggestion! We'll be covering examples in the future. ✅⛩

[@prabirkumar8027]

sir, please do collectionview inside tableview using mvc

[@radomyrbezghin6299]

Okay, then why none of them figures out where to put networking code ? They are basically 3 similar patterns that have exactly the same flaws ...

[@EssentialDeveloper]

They're not flaws - these UI patterns are just not meant to deal with networking. The networking lives in another layer, not the UI ✅

[@PavelPalancica]

@@EssentialDeveloper - But who said we have many layers (to begin with)? Isn't it that most students are taught MVC way before being taught about Multi-Layered Architecture? From this perspective, in case when we just have the UI layer but we need to do some networking - MVC can be seen as app architecture, isn't it? And the Networking layer is just a helper component of the Model layer... Physically it can be a new folder or module, but logically - it's just a bunch of helpers needed to transfer "source of truth" data between client and server.

[@EssentialDeveloper]

Hi @@PavelPalancica You can have as many layers as you want. It's up to you to decide what's best for your app ✅