Hey, I got the same idea when I started working on our SwiftUI/ Combine project a year ago. However, I left the names as it is. Observed is still the ViewModel, Identifiable is still the Model in our architecture. This combined with a variant of clean architecture for our Combine pipelines has made our codebase so neat and intuitive.
Dont think this pattern has clean ios arch, it's already breaking SRP in the view, the view has to talk to network layer, there's no separation of concerns, nor dependency injection this is not testable.
There is no difference from MVVM and what you've described here apart from just putting a different label/name and made such a big claim to "STOP using MVVM". Was expecting at least some challenging arguments and new solutions exclusive for SwiftUI. We us this in our projects.
Good point Jonas. I just wanted to present a SwiftUI specific architecture that I use. BTW Do you know the 60-30-10 Rule of Coding? Check it out here: th-cam.com/video/0ZH2HmMAD5E/w-d-xo.html
Nothing much. That alone makes it super safe and SwiftUI like. Do you love SwiftUI? Let me tell you the 7 things I HATE about SwiftUI: th-cam.com/video/N2i28zxjfvs/w-d-xo.html
That is correct. Being that said IVO is a bit closer to the SwiftUI jargon :) BTW here's a must watch for iOS developers: Clean Code Principles th-cam.com/video/2lD8fjedeis/w-d-xo.html
@@rebeloper Thank you. By the way, when I saw this video I thought it was a bit silly but now I definitely agree - IVO is much cleaner compared to MVVM, going to use this from now on.
Correct. More restrictions, much more readable, SwiftUI like :) Till than take a look at my lates video about 30 Xcode Keyboard Shortcuts You NEED to Know: th-cam.com/video/CWjHI3vZLSk/w-d-xo.html
Kinda, but there's more to it. BTW are you using keychain to secure your data? Watch this video where I explain how easy it is to use keychain in Swift: th-cam.com/video/csssezPchoI/w-d-xo.html
If you return something that is unstable, like UUID() or an index, this means you get a new object each time you get the object and this will kill reusability and can cause epic memory and layout process usage beside view management issues like transition management and etc.
He’s just creating flat scopes that will inevitably cause massive memory and scoping issues for redrawing once you have to add more than a single screen to your test app. Would not recommend doing anything similar to this. There’s really no pattern here, and the way he’s managing the view model makes me think he doesn’t even understand why you’d want a view model in the first place or how you’d write tests to cover this monstrosity
Recently I've been using custom property wrappers instead of MVVM :) Did you wonder if will AI replace programmers? Check out my take on it 👇 th-cam.com/video/9NlECBGI-OM/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
Why I like the concept for it simplicity it may end up creating difficulty for a medium or large project. The layers are tightly coupled so maintaining the code will become a big issues quickly. I always advocate for separating business logic from every other layer/part of your code and business layer should never depend on any concrete implementation of any other part of your code.
This doesn't changes anything to MVVM, is the same pattern with different naming conventions. Observable could just be @State, and profile doesn't need to conform to Identifiable if you're not going to use that conformances for something, like display the fetched entities in it in a list, which is not the case since your fetch fetches a single profile.
It makes it more robust :) Next watch Xcode Meets AI: Take Your App Development to New Heights 👇 th-cam.com/video/xwcPYSezBxA/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
I like to have them also in the View and complete/throw with optional errors so I can show the on the View as an Alert :) Of course the logic should definitely be done on the view model. If you enjoyed this video make sure to check out my newest tutorial about iOS15 availability: th-cam.com/video/u1SMCxmYMvE/w-d-xo.html
@@rebeloper is it also okay to have another observed value within the extension that has a cleaner payload of erro? So one can just mutate view depending on the cleaner observed Error?
You have to learn the pros and cons so you can decide if and how you're going to use it. Did you wonder if will AI replace programmers? Check out my take on it 👇 th-cam.com/video/9NlECBGI-OM/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
Hello, thanks for the explanation, I applied it in a demo that I am making to practice SwiftUI, but I have a doubt, Could you give me an example of where I should declare an EnviromentObject? would it be inside the View or inside the Observed class?
Let me explain in detail in a mentoring session rebeloper.com/mentoring Best iOS Development Tools - Summer Sale 👇 th-cam.com/video/HzGgXjyF8ak/w-d-xo.html
Yes, you are right. Made it really "tight", SwiftUI specific. BTW here are 6 things I wish I knew about SwiftUI when I started 👇 th-cam.com/video/EZz9NL4H0Ug/w-d-xo.html
Thanks for the suggestion. Will consider it. Next watch Mastering App Distribution With TestFlight And App Store Connect 👇 th-cam.com/video/GyD6t0GnWp0/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
It's just personal preference :) both work fine. If you liked this one you will love my latest video on Timers: th-cam.com/video/oo-sW_Ds968/w-d-xo.html
Thank you for this tutorial. It is the cleanest and easiest to understand. I've viewed many MVVM tutorials, and they are usually convoluted by using components that detract from the basic inter-file communication. This makes it more overwhelming to visualize. Your example is straight and to the point, with no distracting "extras". I also really like your teaching style, and look forward to following more of your tutorials. Thanks again!
Thank you for the kind words. Glad you like my teaching style. I also do 1:1 mentoring: rebeloper.com/mentoring BTW Find out How to Create Custom a Framework in Swift within minutes 👉 th-cam.com/video/2k4mMdLfIKY/w-d-xo.html
HI Rebel! Im new-ish in iOS dev, curious to know use cases for this pattern? Should I use this for my job or personal project? I do like how this reduces the amount of models (or view models) to create especially if the Model or ViewModel is for that specific View only while at the same time easier to set up in the beginning. This almost feels like MVVM, with the difference of naming and access. Is this still easy to test?
Works exactly the same. No changes are required. BTW are you using NavigationView or NavigationStack in your SwiftUI projects? STOP using Navigation Stack in SwiftUI! Use THIS instead... 👇 th-cam.com/video/LR0uK5Mc2CM/w-d-xo.html
Either use @environmentObject or move it into the Views with @ObservedObject. I can show it to you in a mentoring session: rebeloper.com/mentoring BTW check out this New MUST HAVE SwiftUI View 👉 th-cam.com/video/qJNy-u5gbq8/w-d-xo.html
I do not use MVVM at all with CoreData. The property wrappers provided by SwiftUI are more than enough, so I use only the views. SwiftData is even easier. BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇 th-cam.com/video/9lRWau51lGw/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
For that case I would set up the shared ObservableObject as an environment object. Next Unlock the Power of Core Data Versioning! 👇 th-cam.com/video/RDtLWWos3cA/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
You seem to be promoting MVVM, even though you say otherwise. One of the hallmarks of MVVM is testability, and I find it odd that the folks taking the time to write articles about why MVVM doesn't work with SwiftUI, conveniently leave out how one might otherwise unit test their code.
You're perfectly right. My suggestion is MVVM just pinpointed for SwiftUI specifically. Also yes, testing is great with MVVM. Next: Make Sure You Always Get the Best Error Alerts! 👇 th-cam.com/video/VWgZ99FTuBU/w-d-xo.html
In some cases you do need a VM. But mostly it's just the View. BTW check out these 8 Mind-Blowing Websites You Probably Didn't Know Existed 👉 th-cam.com/video/BGJgBjnCSM0/w-d-xo.html
This looks very interesting. Will try it out. You *almost* addressed something which I've been struggling with, so I'll ask you here..... Hope you don't mind. Many apps have a sign-up/sign-in ability and then a User Profile page that can be filled in. But....what if the properties in the User struct are optional? Mine has `name` and `email` as Strings, but then I have 5-10 other properties which are all optional: dateOfBirth: Date?, gender (an optional Enum), heightInCM (optional Int), and more. Following Peter Friese's Books app, I like the idea of having one view to display the User Profile and clicking "Edit" to update the User's properties. But, if the user edits their profile but only adds *one* value, say their birthdate, and doesn't change the other values, how will they maintain their nil values? I can fake it for anything that uses a TextField, but for Pickers, Toggles, etc....there doesn't seem to be a useful, non-clunky solution. If you have any thoughts, ideas, suggestions - even other places I could ask that are not as judgemental as SO - I'd be happy for any pointers. Thanks again for you interesting video.
Take a look at BetterCodable on GitHub. It addresses the exact issue you are having. If you need me to explain I'm available here: rebeloper.com/mentoring BTW do you want to know why 95% of self-taught developers fail? Find out why here: th-cam.com/video/pZaot8RA84g/w-d-xo.html
I think the author’s efforts in making tutorial videos are helpful for the most part, but going by this video he is completely leading new and inexperienced SwiftUI developers down a rabbit hole filled with frustrations. There’s absolutely no advantage to doing this “pattern” over MVVM. One of the main reasons for these UI patterns is to make it easy to implement automated tests on the code base, but he didn’t even demonstrate how this “pattern” of his makes it easier to test. Meanwhile, why do you use optional/nil parameters for the “UserProfile” struct initializer instead of just using a more idiomatic default initializer/method parameter values? All in all, thank you for making this video but I advise other watchers to be more circumspect with what they “learn” from it.
Thanks for the feedback. I too matured since :) Did you wonder if will AI replace programmers? Check out my take on it 👇 th-cam.com/video/9NlECBGI-OM/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
It is really distracting to watch you look at keyboard every time you type something. Stoping in middle to check what you write and then keep writing. How many years of experience do you have in order not to be able to type without looking at your keyboard?
Basically he is not using protocols at all, difficult to test. He is basically applying basically MVVM with another name, and not making any protocols that conform the VM, thus his code is difficult to test.
Came here for the comments. Another clickbaity video. MVVM all the way. Don’t respond with a link to another video like you do with all your other replies thanks
It's right here: th-cam.com/video/fUk9hLLPvqo/w-d-xo.html BTW here are 18 Commands That WILL Change The Way You Use Terminal Forever 👉 th-cam.com/video/C90lCH-_EBU/w-d-xo.html
It might work for small projects. But for medium and big projects, with thousands of business rules, it will just fail miserably. MVVM remains the best choice for any iOS project, specially big ones.
Thanks for you input. Do you have experience with medium/big projects? BTW let's create a Sudoku Solver In Swift 👉 th-cam.com/video/u7A6mdTq3eU/w-d-xo.html
They do not HAVE to be but it's a good idea. Maybe you're going to use them inside a List... BTW do you want to know why 95% of self-taught developers fail? Find out why here: th-cam.com/video/pZaot8RA84g/w-d-xo.html
The VM approach is also viable for SwiftUI apps, but Apple recommends MVVM as a basis. Find Out How Senior Programmers ACTUALLY Write Code 👉 th-cam.com/video/3PlcehlBlS4/w-d-xo.html
What is your favourite Design Pattern in SwiftUI?
Hey, I got the same idea when I started working on our SwiftUI/ Combine project a year ago. However, I left the names as it is. Observed is still the ViewModel, Identifiable is still the Model in our architecture. This combined with a variant of clean architecture for our Combine pipelines has made our codebase so neat and intuitive.
TCA
Dont think this pattern has clean ios arch, it's already breaking SRP in the view, the view has to talk to network layer, there's no separation of concerns, nor dependency injection this is not testable.
What about clean Swift + VIP?
MVVM is perfect to me
There is no difference from MVVM and what you've described here apart from just putting a different label/name and made such a big claim to "STOP using MVVM". Was expecting at least some challenging arguments and new solutions exclusive for SwiftUI. We us this in our projects.
Good point Jonas. I just wanted to present a SwiftUI specific architecture that I use. BTW Do you know the 60-30-10 Rule of Coding? Check it out here: th-cam.com/video/0ZH2HmMAD5E/w-d-xo.html
Besides the naming and nesting one type into another, how exactly this pattern differs from a regular mvvm?
Nothing much. That alone makes it super safe and SwiftUI like. Do you love SwiftUI? Let me tell you the 7 things I HATE about SwiftUI: th-cam.com/video/N2i28zxjfvs/w-d-xo.html
15 minutes in and I am thinking the same exact thing.
I wanna ask the same thing 🤣
This is basically MVVM but the Model has to be identifiable and the view model is inside the View
That is correct. Being that said IVO is a bit closer to the SwiftUI jargon :) BTW here's a must watch for iOS developers: Clean Code Principles th-cam.com/video/2lD8fjedeis/w-d-xo.html
@@rebeloper Thank you. By the way, when I saw this video I thought it was a bit silly but now I definitely agree - IVO is much cleaner compared to MVVM, going to use this from now on.
So just Model, View, ViewModel EXCEPT we call it Identifiable, View, Observed. GENIUS.
Correct. More restrictions, much more readable, SwiftUI like :) Till than take a look at my lates video about 30 Xcode Keyboard Shortcuts You NEED to Know: th-cam.com/video/CWjHI3vZLSk/w-d-xo.html
IMO You just renamed ViewModel class in MVVM to Observed
Kinda, but there's more to it. BTW are you using keychain to secure your data? Watch this video where I explain how easy it is to use keychain in Swift: th-cam.com/video/csssezPchoI/w-d-xo.html
If you return something that is unstable, like UUID() or an index, this means you get a new object each time you get the object and this will kill reusability and can cause epic memory and layout process usage beside view management issues like transition management and etc.
Thanks for the input.
🙀 Check out CoreData in SwiftUI 4: What You Need to Knowth-cam.com/video/L3uLEXFCaVI/w-d-xo.html
He’s just creating flat scopes that will inevitably cause massive memory and scoping issues for redrawing once you have to add more than a single screen to your test app. Would not recommend doing anything similar to this. There’s really no pattern here, and the way he’s managing the view model makes me think he doesn’t even understand why you’d want a view model in the first place or how you’d write tests to cover this monstrosity
Recently I've been using custom property wrappers instead of MVVM :)
Did you wonder if will AI replace programmers? Check out my take on it 👇
th-cam.com/video/9NlECBGI-OM/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
Why I like the concept for it simplicity it may end up creating difficulty for a medium or large project. The layers are tightly coupled so maintaining the code will become a big issues quickly. I always advocate for separating business logic from every other layer/part of your code and business layer should never depend on any concrete implementation of any other part of your code.
I couldn't agree more, Paul. BTW Here I talk about The Harsh Reality of Being a Software Engineer 👉 th-cam.com/video/IxweswL5SjI/w-d-xo.html
This doesn't changes anything to MVVM, is the same pattern with different naming conventions.
Observable could just be @State, and profile doesn't need to conform to Identifiable if you're not going to use that conformances for something, like display the fetched entities in it in a list, which is not the case since your fetch fetches a single profile.
It makes it more robust :) Next watch Xcode Meets AI: Take Your App Development to New Heights 👇
th-cam.com/video/xwcPYSezBxA/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
No offense but i feel like put functions in the views kind of messy to me , I prefer mvvm I’d say
I like to have them also in the View and complete/throw with optional errors so I can show the on the View as an Alert :)
Of course the logic should definitely be done on the view model.
If you enjoyed this video make sure to check out my newest tutorial about iOS15 availability: th-cam.com/video/u1SMCxmYMvE/w-d-xo.html
@@rebeloper is it also okay to have another observed value within the extension that has a cleaner payload of erro? So one can just mutate view depending on the cleaner observed Error?
A function may be in the View if it just concerns the User Interface layer.
Well, I learnt how mvvm works thanks to you.
You have to learn the pros and cons so you can decide if and how you're going to use it.
Did you wonder if will AI replace programmers? Check out my take on it 👇
th-cam.com/video/9NlECBGI-OM/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
Hello, thanks for the explanation, I applied it in a demo that I am making to practice SwiftUI, but I have a doubt,
Could you give me an example of where I should declare an EnviromentObject? would it be inside the View or inside the Observed class?
Let me explain in detail in a mentoring session rebeloper.com/mentoring
Best iOS Development Tools - Summer Sale 👇
th-cam.com/video/HzGgXjyF8ak/w-d-xo.html
Looks like MVVM with a different naming ) But anyway, thank you for the video )
Yes, you are right. Made it really "tight", SwiftUI specific. BTW here are 6 things I wish I knew about SwiftUI when I started 👇
th-cam.com/video/EZz9NL4H0Ug/w-d-xo.html
can you do a video about TCA architecture>?
Thanks for the suggestion. Will consider it.
Next watch Mastering App Distribution With TestFlight And App Store Connect 👇
th-cam.com/video/GyD6t0GnWp0/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
Why did you use an optional value instead of a default parameter value?
It's just personal preference :) both work fine. If you liked this one you will love my latest video on Timers: th-cam.com/video/oo-sW_Ds968/w-d-xo.html
I was just wondering the same thing 🤷 He just complicated a well known and simpler way of overloading methods/initialisers 🤦
Thank you for this tutorial. It is the cleanest and easiest to understand. I've viewed many MVVM tutorials, and they are usually convoluted by using components that detract from the basic inter-file communication. This makes it more overwhelming to visualize. Your example is straight and to the point, with no distracting "extras". I also really like your teaching style, and look forward to following more of your tutorials. Thanks again!
Thank you for the kind words. Glad you like my teaching style. I also do 1:1 mentoring: rebeloper.com/mentoring
BTW Find out How to Create Custom a Framework in Swift within minutes 👉 th-cam.com/video/2k4mMdLfIKY/w-d-xo.html
HI Rebel! Im new-ish in iOS dev, curious to know use cases for this pattern? Should I use this for my job or personal project? I do like how this reduces the amount of models (or view models) to create especially if the Model or ViewModel is for that specific View only while at the same time easier to set up in the beginning.
This almost feels like MVVM, with the difference of naming and access. Is this still easy to test?
You are correct about IVO. I would use this in a Team if the team would agree to use it, considered the upsides of IVO over MVVM. Yes it is testable
Going to try to use IVO for my second app. Wish me luck!
You can do it, Thomas! Let me know if you have any issues. BTW are you a PRO developer? TRY THIS: th-cam.com/video/fw8NIizbYMU/w-d-xo.html
which Xcode theme you are using, it looks decent and clean.
It's detailed in this video: th-cam.com/video/fUk9hLLPvqo/w-d-xo.html
What about when using concurrency (async/await)? How does that work with IVO?
Works exactly the same. No changes are required. BTW are you using NavigationView or NavigationStack in your SwiftUI projects? STOP using Navigation Stack in SwiftUI! Use THIS instead... 👇
th-cam.com/video/LR0uK5Mc2CM/w-d-xo.html
How would you share an observed object between several views?
Either use @environmentObject or move it into the Views with @ObservedObject. I can show it to you in a mentoring session: rebeloper.com/mentoring
BTW check out this New MUST HAVE SwiftUI View 👉 th-cam.com/video/qJNy-u5gbq8/w-d-xo.html
Very interesting. Just wondering how this would simplify getting automatic coredata database updates that @FetchRequest offers
Thanks
I do not use MVVM at all with CoreData. The property wrappers provided by SwiftUI are more than enough, so I use only the views.
SwiftData is even easier.
BTW have you seen Firebase Login in SwiftUI: Step by Step Masterclass 👇
th-cam.com/video/9lRWau51lGw/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
@@rebeloper I understand thanks!
And can’t wait for SwiftData to be fully ready for use!
Yeah, check the video about the beta here: th-cam.com/video/0CQHc9Wz25Q/w-d-xo.htmlsi=W3kvc0wtNji1asUz
the init func is really a bad practice,
why not give Date() instead of nil as the default value
That approach is also valid. Find Out How Senior Programmers ACTUALLY Write Code 👉 th-cam.com/video/3PlcehlBlS4/w-d-xo.html
Just curious: with this approach, how do you handle the case where one observed resource needs to be shared and observed by multiple views ?
For that case I would set up the shared ObservableObject as an environment object.
Next Unlock the Power of Core Data Versioning! 👇
th-cam.com/video/RDtLWWos3cA/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
You seem to be promoting MVVM, even though you say otherwise. One of the hallmarks of MVVM is testability, and I find it odd that the folks taking the time to write articles about why MVVM doesn't work with SwiftUI, conveniently leave out how one might otherwise unit test their code.
You're perfectly right. My suggestion is MVVM just pinpointed for SwiftUI specifically. Also yes, testing is great with MVVM.
Next: Make Sure You Always Get the Best Error Alerts! 👇
th-cam.com/video/VWgZ99FTuBU/w-d-xo.html
I agree! View in SwiftUI is the View Model.
In some cases you do need a VM. But mostly it's just the View. BTW check out these 8 Mind-Blowing Websites You Probably Didn't Know Existed 👉 th-cam.com/video/BGJgBjnCSM0/w-d-xo.html
i heard is first time, from you, thank you to make us noticed
Glad you like it. BTW Becoming A Front End Developer Takes Time 👉 th-cam.com/video/Hx2tE19jYn8/w-d-xo.html
Hmm interesting : ) what about navigation?
I cover navigation here: th-cam.com/video/yLLzD4Nm1Rk/w-d-xo.html
This looks very interesting. Will try it out.
You *almost* addressed something which I've been struggling with, so I'll ask you here..... Hope you don't mind.
Many apps have a sign-up/sign-in ability and then a User Profile page that can be filled in. But....what if the properties in the User struct are optional? Mine has `name` and `email` as Strings, but then I have 5-10 other properties which are all optional: dateOfBirth: Date?, gender (an optional Enum), heightInCM (optional Int), and more. Following Peter Friese's Books app, I like the idea of having one view to display the User Profile and clicking "Edit" to update the User's properties. But, if the user edits their profile but only adds *one* value, say their birthdate, and doesn't change the other values, how will they maintain their nil values? I can fake it for anything that uses a TextField, but for Pickers, Toggles, etc....there doesn't seem to be a useful, non-clunky solution.
If you have any thoughts, ideas, suggestions - even other places I could ask that are not as judgemental as SO - I'd be happy for any pointers.
Thanks again for you interesting video.
Take a look at BetterCodable on GitHub. It addresses the exact issue you are having. If you need me to explain I'm available here: rebeloper.com/mentoring
BTW do you want to know why 95% of self-taught developers fail? Find out why here: th-cam.com/video/pZaot8RA84g/w-d-xo.html
I think the author’s efforts in making tutorial videos are helpful for the most part, but going by this video he is completely leading new and inexperienced SwiftUI developers down a rabbit hole filled with frustrations.
There’s absolutely no advantage to doing this “pattern” over MVVM. One of the main reasons for these UI patterns is to make it easy to implement automated tests on the code base, but he didn’t even demonstrate how this “pattern” of his makes it easier to test.
Meanwhile, why do you use optional/nil parameters for the “UserProfile” struct initializer instead of just using a more idiomatic default initializer/method parameter values?
All in all, thank you for making this video but I advise other watchers to be more circumspect with what they “learn” from it.
Thanks for the feedback. I too matured since :)
Did you wonder if will AI replace programmers? Check out my take on it 👇
th-cam.com/video/9NlECBGI-OM/w-d-xo.html&ab_channel=Rebeloper-RebelDeveloper
Love this refinement on the MVVM pattern. I’ve implemented similar patterns in Angular2 in the web side.
Nice walkthrough Alex!
Cool, thanks! 🎉 Just updated StoreKitPro 👉 th-cam.com/video/-gkvRIVEZss/w-d-xo.html
how about the memory cycle in Observed's completion ?)
Could you elaborate? Find Out How Senior Programmers ACTUALLY Write Code 👉 th-cam.com/video/3PlcehlBlS4/w-d-xo.html
looks like renamed MVVM with outdated GCD
Kinda. 🤑 Do you want to make MONEY with your iOS apps? Learn how to here: th-cam.com/video/37qEN4flc3I/w-d-xo.html
It is really distracting to watch you look at keyboard every time you type something. Stoping in middle to check what you write and then keep writing. How many years of experience do you have in order not to be able to type without looking at your keyboard?
Programming is not about typing ;P
Let me show you a Progress Button in SwiftUI 👇
th-cam.com/video/kF8Qk28-FFU/w-d-xo.html
Can you show us how to write Unit Tests with this pattern?
Sorry, SwiftUI is not going well with Test... for now. BTW Becoming A Front End Developer Takes Time 👉 th-cam.com/video/Hx2tE19jYn8/w-d-xo.html
Basically he is not using protocols at all, difficult to test.
He is basically applying basically MVVM with another name, and not making any protocols that conform the VM, thus his code is difficult to test.
Came here for the comments. Another clickbaity video. MVVM all the way. Don’t respond with a link to another video like you do with all your other replies thanks
Did you find the comments helpful?
How?! How did you change -> to an arrow?
It's right here: th-cam.com/video/fUk9hLLPvqo/w-d-xo.html
BTW here are 18 Commands That WILL Change The Way You Use Terminal Forever 👉 th-cam.com/video/C90lCH-_EBU/w-d-xo.html
It might work for small projects. But for medium and big projects, with thousands of business rules, it will just fail miserably.
MVVM remains the best choice for any iOS project, specially big ones.
Thanks for you input. Do you have experience with medium/big projects? BTW let's create a Sudoku Solver In Swift 👉 th-cam.com/video/u7A6mdTq3eU/w-d-xo.html
Did we watch the same video? This is literally MVVM...
Why does *struct Profile* have to be *Identifiable* ?
They do not HAVE to be but it's a good idea. Maybe you're going to use them inside a List...
BTW do you want to know why 95% of self-taught developers fail? Find out why here: th-cam.com/video/pZaot8RA84g/w-d-xo.html
If you use the profiles in List or ForEach, the profile needs to be Identifiable.
Can the identifiable be a Core Data Entity?
Sure! Make sure that you create an id property that you can manually use.
This is just MVVM renamed
MVVM refrained for SwiftUI, I would say :)
Next: Make Sure You Always Get the Best Error Alerts! 👇
th-cam.com/video/VWgZ99FTuBU/w-d-xo.html
As my opinion this approach is bad shit. We can use only VM (veiw, model) for SwiftUI app.
The VM approach is also viable for SwiftUI apps, but Apple recommends MVVM as a basis. Find Out How Senior Programmers ACTUALLY Write Code 👉 th-cam.com/video/3PlcehlBlS4/w-d-xo.html
Please stop using the clean architecture label in this videos. This is just MVVM with makeup
Why is that not clean 🤔