Thank you!

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

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

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

Glad you liked it!

Thanks! Glad you liked it 🙂

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

Thank you!

Thank you! It's draw.io

@@EssentialDeveloper thanks!

Thank you and welcome to the channel! ✅

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 ✅

Hi Mohamed, watch parts 6 and 7 in this playlist: ukposts.info/have/v-deo/e5uqoKidgqyXknU.html

Thanks 😊 you are awesome 😎

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

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

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

Glad it was helpful!

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

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

Glad to hear it!

Hi! We use draw.io

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

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

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

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

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. ✅

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

Welcome on board!

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

@@EssentialDeveloper thank you :) appreciate it.

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! ✅⛩

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

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. ✅

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.

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.

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. ✅

@@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.

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. ✅

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

@@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.

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