I am new to iOS development, so please excuse me in case my question sounds trivial.
I am planning to introduce MVP or VIPER pattern. I am from Web background and in web application we used to follow different layers/dlls (for model, view, common etc.). Does it make sense to follow the same layered approach (frameworks in this case) in iOS and or it will be overkill? I have not come across any sample project (based on MVP) which create different framework for model, View and Presenters? It would be great if someone can share any sample project (based on MVP) which we can use as a starter project.
Thanks In Advance
In iOS, we generally use MVC - Model/View/Controller. So, if you're looking for the analog in the iOS world, that's it. If you're saying that you've really dug into MVC and there's something that you find deeply unsatisfying, and therefore want to introduce a different pattern, then that's a different question.
So, no, the sort of logical separation of responsibilities that you see in approaches like MVC is not overkill. In fact, the division of "view" and "controller" classes are fairly central to everything we do (e.g.
UIViewController subclasses, etc.), so the only thing you really have to do is design appropriate "model" classes and you're off to the races.
But, in answer to your question, you don't generally use separate framework targets for the model, the views, and the controllers. That probably would be overkill. Usually you can keep track of everything through through judicious use of Xcode groups/folders within your project. We generally only pull stuff into frameworks for more technical or logistical reasons (live views, app extensions, sharing code between multiple apps, etc. ... see WWDC 2015 Building Modern Frameworks for discussions of when you'd generally use frameworks).
But to the question of MVC vs MVP or VIPER (or MVVM or whatever). I'd suggest that you simply embrace the shared spirit of all of these patterns (namely the separation of responsibilities) and apply it to your iOS MVC code. Once you've got some iOS experience under your belt, you can then re-evaluate this pattern question.