Swift: VIPER Design Pattern (Architecture, 2023, Xcode 14, Swift 5) - iOS Development
Вставка
- Опубліковано 10 кві 2021
- In this video we will learn about the VIPER design/architecture pattern for Swift 5 and iOS. This is a common pattern for large apps to properly isolate objects and their responsibility.
👉🏼 Connect (personal LinkedIn) / afraz-siddiqui
🚀 Follow on LinkedIn / ios-academy
#swift #designpattern #ios
** Like my teaching style? Check out some of my most popular courses!
courses.iosacademy.io
Join this channel to get access to perks, code, groups, and more:
Building Instagram: courses.iosacademy.io/p/build...
Building TikTok: / @iosacademy
SwiftUI for Beginners: ios-academy.teachable.com/p/s...
Join the iOS Academy Community: iosacademy.io/
** Get Skillshare free for 2 Months and learn iOS
www.skillshare.com/r/user/afraz
** Manage all your investments from app earnings on Betterment!
bit.ly/3eBwlI9
** Grow your own UA-cam tech channel with TubeBuddy:
www.tubebuddy.com/iosacademy
Thanks for creating this video! It's pretty easy to understand. But I would like to point out that in your code, there are a few retain cycles with view, presenter, router and interactor. One option you can do is to make those protocols conforms to AnyObject, and mark these references as "weak":
1. router's ref to presenter
2. router's ref to view
3. presenter's ref to view
4. interactor's ref to presenter
Eventually your object relationship will look like this in the memory, where -> means a strong reference
router
^
|
window -> View Controller -> Presenter -> Interactor
Correct me if I'm wrong.
Although slightly dangerous, I think `unowned` would be acceptable also so we can assert that our objects that should exist do exist. The alternative would be a completely unresponsive app that people would have to kill and restart themselves anyway so I guess you pick your problems :)
I have the same question Interactor has a strong reference of the presenter and the presenter has strong reference of the interactor. It will create retain cycle.
That tells a lot about the iOS academy
circular reference can be fixed by replacing one of the strong references with a weak or unowned reference.
I started a new job and they use VIPER. I'd never used it before and I struggled to get through some explanations of VIPER (ADHD).
This explanation was so concise and easy to understand. Thank you so much, man! ❤
I have been trying to learn this from a long time. Finally i found this hands on tutorial instead of those redundant concepts articles. Thank you
Pretty neat & clean. Clear thought process.
I have basic understanding of VIPER & this video has been quite helpful.
Thanks 🙏
-
Request: Please make an extended version where there is a card view that appears from the bottom & can have a link that presents another screen.
+ like a reusable component that shows up from different screens, example from 2 different tabs.
It wud be interesting to see VIPER tackle such a scenario.
Basically its the Router part of VIPER that is fascinating me lately.
Thanks
Finally! Was waiting for that
Get pumped
Good video explaining basics. I would like to see some more informations about coordination between modules. I use approach of adding Coordinator pattern into VIPER. Also, Router should be responsible only for routing not building a module - here is good to use some Module builder by using fabric pattern. This way we use SOLID principles. There is also questionable for me conforming to UITableViewDelegate and UITableViewDataSource in UIViewController component. What do you think about using Presenter to conform to that protocol - then we keep responsibility of proper presentation on the side of Presenter (view shouldn't convert DTO to ViewModel). I am also curious about automation for it. I created Xcode template which creates entire module with 1-click, but I am still researching for making it better - that's why I am looking for more opinions :) . Thank you for your work and I am waiting for part 2 with advanced part.
I can't thank you enough. Keep the good work!
Youre welcome
This is really helpful and clear for me to understand. Thank you!
Youre welcome
They all connect by strong reference between each other? Where are the weak references?
You are doing very good content! At this time I'm exploring all your videos. Keep going 😁
Thanks!
Great video as always! Would you mind explaining how to design an app that will run on “small” devices such as iPhone 7 and on “bigger’s” such as iPhone 12 Pro Max?
Thanks and keep up the good work
amazing job!
Whenever I search for Swift/ iOS, I ended up with this channel :)
I'll just search in this channel first next time lol
it would be nice if you extend this tutorial for navigation on multiple screens, delegates, callbacks and how to handle this in VIPER appropriate. And yeah, thanks for video. Cleanest explanation of VIPER ever I see 👍
Great suggestion!
I was trying to learn VIPER but seems confusing, this video is so simple and easy to understand.
Thanks!
I’m don’t really like VIPER. To much classes. Most of classes knowing about other ones. View layer contacts with models. My preference to Data Driven MVVM + Coordinator (for routing) + Builder (factory to create units) + proxy pattern for fetching data from web or storage. Any way it’s a great video to understand this pattern. Thank you!
I agree
@@iOSAcademy Could you make an app for us demonstrating all of those ? It would be very valuable to see a "best practices" app with them rolled into one, and we could use it as a template for our future apps. Thanks for your great work !!!
Totally agree. Looks like the VIPER is an upgrade for MVP. However, MVP itself is not a perfect architecture due to the dependencies between the presenter and views. In the VIPER, it introduced a new dependency between interactor and presenter, which is a terrible thing. Meanwhile, the too many protocols make it hard to maintain if there's new business logic which requires a new parameter in a protocol, which needs to modify all the implementations of it. MVVM is a perfect architecture since it decouples the dependency of view and view model. The view model no longer needs to hold a reference of view. In Android, we can use live data or data binding to update the view, in iOS we can use RxSwift or things like that.
@@noodles7240 yes, that’s true. But I’m usually use closures to bind vm and view.
Viper is a little bit confusing, but we can isolate the modules, functionalities, I think it was easier to test. Thank you so much for the great lesson! (:
Youre welcome
Great content👍, I love when u start project without storyboard. VIPER is one of the design pattern that I want master but always fail. Hope with this tutorial I’ll get proper understanding.
Көп қолданылады ма VIPER Қазақстанда?
@@flutterswift7278 Банктерде колданылады
And finally i understood the VIPER, thanks a lot man
Youre welcome
Thanks, very nice video! My question is, wouldn't it be better to create an AnyEntity protocol, conform the User entity to it, and instead of the update with users method you could write a more generic update with data anyentity function?
Thanks for the tutorial. I have question about the code written to create table, label etc. It is a function right, doesnt it get called everytime table or label is accessed and keeps creating new instance of table or label?
Great video! Thank you a lot!
You are welcome!
Hi! great learnings in your video and understood VIPER easily because of your video. I have a question that does your code produces retain cycles in router class where interactor, presenter, view contains each other references ?
Thanks
Great Explanation helps a lot . 🙌🏻
Glad to hear that!
THANK U SO MUCH!!!
IT REALY USEFUL!!!
FROM RUSSIA WITH LOVE ❤️❤️❤️
Youre welcome
Great content, very good explanation
Thanks!
Hi do you have git for this? It would be better if also inspect on code to learn better
A great intro to VIPER. Actually, go ahead and watch it!
Thanks
Couldn't manage to *destroy* that like button. It still works.
Haha nice
Excellent tutorial
Thanks!
What I do is that presenter will have reference to View, Interactor and router but only the View will have reference to the presenter. Interactor and Router does not need to have a reference of the Presenter. With using async and await the presenter will wait for interactor to do the network calls and return the data. Its also a good practice to have a separate helper class for the network calls instead of writing them completely in the interactor.
Awesome vid
Thanks
"Main storyboard file base name" doesnt show in my plist file but when I try to run the app it seems it is still there. Is there a chance it is hidden somehow?
Thanks bro
Youre welcome
Thanks for the great video and explanation. Is there a github link to take a look at this sample project code?
Thanks - code available through iosacademy.io/resources
Can you send a link to the project please?
I think which pattern to use it's depends on project what you are working on. If it's small app then you can use only MVC. But, of course Viper, MVP and so on need to know :)
Yep, i completely agree
I think maybe the pattern is a bit convoluted... I can’t see myself using it, to be honest. But great video, I learned a lot! Thank you a bunch!!
hey, excellent video! and channel, to be honest. but i have a question: why is the router aware of the view? as i understand it, thats not compatible with the diagram of VIPER at the beginning of the video.. shouldnt it interact with it through the presenter? i think its more tedious, but cleaner.
Good call out. Ive seen both approaches
Oh my god😭👍👍👍
Haha thanks
Waiting for the Clean architecture implementation. Can be Clean VIPER, Clean MVVM,...
why does the interactor had to have a reference to presenter? doesn't it better if the interactor just return a result? hence it did not know anything about the caller = less coupled
22:38
“let” was pronounced very sensually :))
p.s. Thanks for lesson!
I want to learn Viper but, I stuck how to implement uitabbarcontroller in viper. Can you show it how next time?
Thanks for video, where can I get the source code?
Please make a video using VIP architecture pattern for Swift 5
Thanks for this great tutorial, however, I still don't understand why entity (users) has to be in view! I think it would be better if it was in the interactor. also why we should have an API call in the router?! it also should be in the Interactor 🤔
I understand that this is just for learning purposes, but I am guess there is a cyclic dependency that gets created here.
The view has a reference to presenter and the presenter has a reference to view.
Thank you! VIPER has been so overrated. It is so clear now. Can you share the source code for this kind of tutorial?
Youre welcome
FYI- the "Any" prefix is intended to refer to a type erased opaque type that conforms to the protocol.
yep!
What to to next? If I wanna tap the cell to get a network request and push to another Controller? Where and how I should write the codes?
You would use the router to move to the next screen
Can we use viper and combine together ?
Yes
Great example! The only question left is why is the users array inside the view object? View doesn't need to know anything directly about the entity.
have you found the answer yet? I found another viper example also did the same.
where to put validation code and how to pass data from one viewcontroller to other ?
You can use the router for that, since it is the router's responsibility to contain the logic for the flow of screens. This VIPER tutorial is good, but Viper is not really adequate for one screen apps, but rather for large apps with a lot of business logic in it. Validation code in what sense?
My most favourite part of the video: 02:49
Haha thanks
Lots of bad practices detected! But in general good introduction into the pattern itself
It is got to solve the retain cycle.
Yep
protocol is declared as AnyInteractor , AnyPresenter etc, but the methods like getUsers, didfetchusers inside protocols are confusing, i think they should be generic.protocols should not be concrete.
Is the source code for the same is available?
Yes, for channel members
I don't know, maybe because I'm just a beginner I'm thinking it's a little too much setup, and really I can't get what are the benefits viper brings.
It is a lot but with huge projects it is a clean design
@@iOSAcademy By huge you mean, FANG level of hugeness correct, or am I missing something? Anything less than that I can use MVC or MVVM?
Eh, its subjective. Like airbnb isnt fang but uses it. And othrs too
@@gasparfreak I work in a smaller company than FANG, ain't that big of an app and we use it too. It's good when you have a lot of business logic inside your app. If an app is heavily based on networking, I don't think Viper would be the best, MVC or MVVM is probably better
2:48 'insert sponser'
How you navigate so quickly without using touchpad?
Command shift O
Uuumm... I'll stick to MVVM. Thank you.
Wow, this is so fast! Did you practice this 3 or 4 times before recording this video? I'll have to watch it 2 or 3 times to fully inject it into my head but it seems to make sense. Personally, I think VIPER is overkill. Why take something simple and make it so complicated? I hate when things are over-engineered. It just seems like someone is trying to provide job security for themselves. There are no comments in this code. I would hate to have to try and figure this out. I would be cursing the developer and wondering "why, why, why" so many times. I seriously don't understand the point of it, but my new employer wants it probably because some manager heard it was new.
Do you really need the "{ get set }" stuff?
Near the end, when you were not getting any data showing up, I thought it might have been because you were missing that annoying "Allow arbitrary loads" setting in your info.plist file but for some reason, you didn't need that. Not sure why.
Haha thanks - no, just experience
Good overall I think, I skipped around a bit. I'm already familiar with VIPER and PRESIDIO (RIB architecture) and I've used both extensively but I like to get other perspectives on these things because I feel like there's always something I can do better.
One major problem here though is that you added some specific use case functionality to your core Any* protocols. These functions should really be in separate protocols that extend the Any* protocols and then our concrete classes would implement those.
For example `AnyPresenter` shouldn't be calling for user lists (unless all of your presenters would do that, which still seems like a fundamental flaw) but rather you'd have perhaps an
`AnyUserPresenter`, then your `UserPresenter` would implement that protocol.
It adds another layer of protocols which can be convoluted for an example but the good side of this is that you can now mock out these objects easily in test or swap implementations and do cool things with experimentation in production that would allow you, for example, to switch to a different type of UserView on the fly, with maybe a different UserPresenter that would give a different view into the same data more or less.
I *think* you did this intentionally to water down the number of protocols and make the arch less overwhelming to pick up on, but good overview all around. nice work :)
one more thing, the `start()` method name I think is a bit misleading, but this looks more like a `bootstrap` or `build` factory method, I would expect `start` to be a type of lifecycle method that fires on `viewDidLoad` for example
I am a Korean developer studying viper.
Thanks for the detailed explanation. Then, is it better to inherit the two protocols by describing common tasks in Any* protocol and user-related tasks in User* protocol?
@@eaststone that’s right! That’s what I would do. I would extract all common behavior for your Any* protocols and then make more specific use cases for each scenario like in a User* protocol.
You can implement as many protocols as you want and you can separate them in swift using extensions and even put the extensions in separate files. With the caveat that extensions can’t have stored properties. So you’d have to declare those in the main class. This would probably only be used to keep your file sizes smaller once they get too large.
Happy coding!
@@sexypekk Thank you!!! 👍
@@sexypekk Sorry, but I have one more question.
I think protocols are meaningful for bundling repetitive code into blueprints. So, why implement a function for User as a protocol? This seems to be something used only in User *Class. Is there a big difference between implementing a function for User as a protocol versus implementing it inline?
Don’t think it is appropriate to make reference to User in the protocol definitions, should be generic to work across modules. Also an example of routing would be useful.
Can we have source code
Coming soon
600 th like
Thanks!
If you have such a good pattern, use it yourself. When people understand patterns, they become the ability to make patterns.
Do not deprive them of the opportunity to develop the ability to design optimal patterns by themselves trying to understand the patterns you have made. Any pattern is very boring and boring.
This isnt my pattern. Its common across industry
Very fast-paced video and hard to understand. You got to the implementation so fast and confused me about where to put all these protocols and connections
Thanks for the feedback
ok i was following until 21:25 then you lost me, you shouldn't be calling an api inside the initialiser
yeah I thought the same. This can cause a race condition.
why don't you ever share the code source ughhh
It would have been cool if the actual View/Interactor/Presenter actually take their references in the initializer, that way we wouldn't need to declare them as { get set } in the actual protocol, just { get }.
protocol AnyView {
var presenter: AnyPresenter { get }
}
class ViewController: UIViewController, AnyView {
weak var presenter: AnyPresenter? // avoid retain cycle
init(presenter: AnyPresenter) {
self.presenter = presenter
}
}
// etc.
Thanks for video, where can I get the source code?