6 ms·

I made a new account just to ask this: 'MVC works really well and scales really well" Is this a joke? Do you have any professional iOS experience? MVC is famou

I made a new account just to ask this: 'MVC works really well and scales really well" Is this a joke? Do you have any professional iOS experience? MVC is famous for scaling terribly on iOS and resulting in view controllers with thousands of lines. MVC is great for small apps. No need to overcomplicate things. But if you're building something bigger, you should look into using the right tool for the job. Don't blindly follow a popular pattern, but choose the right pattern to make the code easy to read, easy to test, and easy to modify.

Apocryphon 5y ago
The problem is that the Cocoa framework, even after the advent of Swift, has always been created with MVC in mind. We're now at a point in iOS where trends have rolled around and now people are saying to pick MVC because that was Apple's intention, other architectures were created because people were doing it wrong: https://medium.com/flawless-app-stories/the-only-viable-ios-architecture-c42f7b4c845d https://medium.com/flawless-app-stories/the-only-viable-ios-... Obviously most significant production apps are using variant architectures such as at the bare minimum having view models, and the introduction of SwiftUI and popular earlier frameworks such as RxSwift also complicates things. Most apps aren't using pure MVC, sure, but it doesn't mean that the architecture isn't scalable. The alternatives might also be pretty gnarly: https://developer.squareup.com/blog/ziggurat-ios-app-architecture/ https://developer.squareup.com/blog/ziggurat-ios-app-archite...
- swiftaccount1 5y ago
  That's an interesting article. I find iOS architecture fascinating and spend a lot of time thinking about it. It seems like "MVC" in common usage (based on talking to other iOS devs) means spaghetti, but I guess it doesn't have to be like that. To me that article proposes a more disciplined MVC than what I've seen in real codebases. I think a lot of the architectures people come up with (like the second one you linked) try to build that discipline in. I try not to be dogmatic and instead go to core principles. Do I know what this class is supposed to be doing? Are my data and view layers reasonably separated with minimal glue code? Can a new dev easily navigate this project? It's an endless discussion with no right answer. Thanks for sharing!
  - smoldesu 5y ago
    > I find iOS architecture fascinating and spend a lot of time thinking about it. > It's an endless discussion with no right answer. These don't seem like the hallmarks of a well-designed, mature platform.
jmull 5y ago
There's nothing about MVC that makes you put thousands of lines in a controller. I don't know of any software development patterns that will stop you from writing spaghetti code or adopting "ball of mud" design if you decide to do that.
- swiftaccount1 5y ago
  I'm not sure if I fully agree with that. It's true that you can spaghetti with any pattern, but I think on multi dev teams it helps to have guidelines about what goes where to ensure a clear separation of responsibilities. Someone linked another thought provoking article here about how MVC does not have to equal spaghetti which I found interesting. But I also think we need to take a step back and ask, "why have so many ended up with the same result?"
  - 3grdlurker 5y ago
    Well I also used to make giant controllers when I was a beginner. That’s why you can pretty much “spaghetti with any pattern”. Over time I realized that I can just create dedicated controllers or handlers or managers or services with more specific and limited functionality, and then my VCs simply dispatch to those. It’s called composition.
- nsonha 5y ago
  Yes there is, model and view are dumb roles which makes controller do everything under the sun
  - gurkendoktor 5y ago
    Even when you are in a situation where most of your code belongs in the controller layer, nobody forces you to put it all in one class.
    - nsonha 5y ago
      which begs the question what do you need MVC for, what is it if not a way of structuring code? If you can just structure your code by splitting to multiple files abitrarily, regardless of MVC
mpweiher 5y ago
> MVC is famous for scaling terribly on iOS You have to distinguish between MVC, which scales really well, and what Apple calls "MVC", which does not. https://blog.metaobject.com/2015/04/model-widget-controller-mwc-aka-apple.html https://blog.metaobject.com/2015/04/model-widget-controller-... And yes, the fact that they overloaded the term is a problem. https://blog.metaobject.com/2017/03/concept-shadowing-and-capture-in-mvc.html https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...
deleted 5y ago
[deleted]
3grdlurker 5y ago
> Is this a joke? Do you have any professional iOS experience? Let’s just say that I can build a view controller for a large, multi-sectioned list where each section calls a different APIs and shows items with different layouts, and still end up with less than 500 lines of VC code even with generous line breaking. Oh, and I can make custom UICollectionView layouts with self-sizing headers and cells. That said, your comment is just ad hominem and you should be downvoted to oblivion.
- swiftaccount1 5y ago
  Yeah, sorry for the choice of words; I just fired something off with no editing. In my mind, I was thinking of MVC at it's worst (which is unfortunately common). That being said, would love to learn more about how you structure code. What does a project structure look like for you? I usually conceptually try to separate the view and data starting with the simplest file structure and dividing as needed.
- gregkerzhner 5y ago
  How do you manage data flow from your view layer to your API layer? Like for example, if a UITableViewCell has a button in it which needs to load some data from the API? Do use an event/delegate which flows from the UITableViewCell through the `cellForRowAtIndexPath` method to the controller, out to some other class? It must feel pretty great to have your business logic and API layers abstracted into other classes, and have your lean view controller just be the glue. Yay MVC! Now imagine that your table view has 20 cells, and each cell is managed by a team of 5 people and needs 1,000 lines of code to fulfill its business logic. How would this approach hold up? Would you have all 100 people working on the same `cellForRowAtIndexPath` method, piping every event for those 20,000 lines of code through there? When people talk about scale on iOS, they are talking about potentially 100s of people working on the same screen. With something like React, this is trivial by having each team work independently on its own components. With iOS, its much harder out of the box.
  - 3grdlurker 5y ago
    > business logic and API layers abstracted into other classes, and have your lean view controller just be the glue That’s pretty much the technique. :) Also, composition by child view controllers.
gregkerzhner 5y ago
I fully agree here - MVC scales terribly. Of course, it's not impossible to come up with a well designed MVC app at scale, but it takes a ton of skill and feels like you are fighting the framework at most steps. One particular challenge is lack of modular components and component nesting. For example, if you have a list view, it's very natural to have one component define the list, and child components define each entry in the list. Something like React makes this trivial. On iOS on the other hand, you are encouraged to use a UITableViewController with UIViews for each cell. This immediately pushes you towards one mega-controller which mixes the responsibilities of the list with those of the individual cells. To overcome this, you could try to have a UIViewController for each cell (uncommon), or have the UIView of each cell start taking on more responsibilities of a UIViewController (breaking MVC). In general though, iOS's MVC is a perfect storm of being both bare bones as well as opinionated at the same time. For these reasons many large corporations have moved away from MVC to their own custom in-house architectures to handle scale. Facebook - https://www.youtube.com/watch?v=mLSeEoC6GjU https://www.youtube.com/watch?v=mLSeEoC6GjU. * Uber - https://github.com/uber/RIBs https://github.com/uber/RIBs * Square - https://github.com/square/workflow https://github.com/square/workflow
ardit33 5y ago
Do you realize that the whole Apple's UIKit Framework is a version of MVC? I have seen many versions for it in iOS, MMVC, MVVC, or whatever, but really they are iterations of separation of business logic and view/display logic. You can disperse the view logic, without having traditional centralized controllers, but your business logic will end up centralized in one place. So, in practice you end up with a Model-Business-Logic / View paradigm, where traditional controllers end up just being a thin layer. Protocol driven development, reminds me the old Java style of having a class (eg. MyFunctionalityClass), which was either abstract, or had only protocols declared, then have another MyFunctionalityClassImpl to actually implement it. I didn't think it was pretty, and it seemed it was done by C++ developers to simulate the lack for header .h files in Java. Ps. Before you reply on a ad-hominen way, I probably have much more iOS experience than you, since I both have worked on it since day one, and have worked on some the currently largest apps in the world.
- swiftaccount1 5y ago
  I basically agree with you, actually. It feels like a lot of this is breaking down into semantics. I’m not fond of acronyms, I believe it’s important to go to core principles and never do anything blindly, but only when it’s useful. The fundamental challenge of iOS architecture is picking the right level of abstraction for the complexity of your application. The trouble that comes in with MVC, as I see it, is how easy it is to shoot yourself in the foot. It’s too easy to do it “wrong”, which is why so many have tried to come up with something different. Of course you can’t escape the MVC-ness of the platform, it’s all about how you manage it.

Apocryphon 5y ago

The problem is that the Cocoa framework, even after the advent of Swift, has always been created with MVC in mind. We're now at a point in iOS where trends have rolled around and now people are saying to pick MVC because that was Apple's intention, other architectures were created because people were doing it wrong: https://medium.com/flawless-app-stories/the-only-viable-ios-architecture-c42f7b4c845d https://medium.com/flawless-app-stories/the-only-viable-ios-... Obviously most significant production apps are using variant architectures such as at the bare minimum having view models, and the introduction of SwiftUI and popular earlier frameworks such as RxSwift also complicates things. Most apps aren't using pure MVC, sure, but it doesn't mean that the architecture isn't scalable. The alternatives might also be pretty gnarly: https://developer.squareup.com/blog/ziggurat-ios-app-architecture/ https://developer.squareup.com/blog/ziggurat-ios-app-archite...

swiftaccount1 5y ago
That's an interesting article. I find iOS architecture fascinating and spend a lot of time thinking about it. It seems like "MVC" in common usage (based on talking to other iOS devs) means spaghetti, but I guess it doesn't have to be like that. To me that article proposes a more disciplined MVC than what I've seen in real codebases. I think a lot of the architectures people come up with (like the second one you linked) try to build that discipline in. I try not to be dogmatic and instead go to core principles. Do I know what this class is supposed to be doing? Are my data and view layers reasonably separated with minimal glue code? Can a new dev easily navigate this project? It's an endless discussion with no right answer. Thanks for sharing!
- smoldesu 5y ago
  > I find iOS architecture fascinating and spend a lot of time thinking about it. > It's an endless discussion with no right answer. These don't seem like the hallmarks of a well-designed, mature platform.

jmull 5y ago

There's nothing about MVC that makes you put thousands of lines in a controller. I don't know of any software development patterns that will stop you from writing spaghetti code or adopting "ball of mud" design if you decide to do that.

swiftaccount1 5y ago
I'm not sure if I fully agree with that. It's true that you can spaghetti with any pattern, but I think on multi dev teams it helps to have guidelines about what goes where to ensure a clear separation of responsibilities. Someone linked another thought provoking article here about how MVC does not have to equal spaghetti which I found interesting. But I also think we need to take a step back and ask, "why have so many ended up with the same result?"
- 3grdlurker 5y ago
  Well I also used to make giant controllers when I was a beginner. That’s why you can pretty much “spaghetti with any pattern”. Over time I realized that I can just create dedicated controllers or handlers or managers or services with more specific and limited functionality, and then my VCs simply dispatch to those. It’s called composition.
nsonha 5y ago
Yes there is, model and view are dumb roles which makes controller do everything under the sun
- gurkendoktor 5y ago
  Even when you are in a situation where most of your code belongs in the controller layer, nobody forces you to put it all in one class.
  - nsonha 5y ago
    which begs the question what do you need MVC for, what is it if not a way of structuring code? If you can just structure your code by splitting to multiple files abitrarily, regardless of MVC

mpweiher 5y ago

> MVC is famous for scaling terribly on iOS You have to distinguish between MVC, which scales really well, and what Apple calls "MVC", which does not. https://blog.metaobject.com/2015/04/model-widget-controller-mwc-aka-apple.html https://blog.metaobject.com/2015/04/model-widget-controller-... And yes, the fact that they overloaded the term is a problem. https://blog.metaobject.com/2017/03/concept-shadowing-and-capture-in-mvc.html https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...

deleted 5y ago

[deleted]

3grdlurker 5y ago

> Is this a joke? Do you have any professional iOS experience? Let’s just say that I can build a view controller for a large, multi-sectioned list where each section calls a different APIs and shows items with different layouts, and still end up with less than 500 lines of VC code even with generous line breaking. Oh, and I can make custom UICollectionView layouts with self-sizing headers and cells. That said, your comment is just ad hominem and you should be downvoted to oblivion.

swiftaccount1 5y ago
Yeah, sorry for the choice of words; I just fired something off with no editing. In my mind, I was thinking of MVC at it's worst (which is unfortunately common). That being said, would love to learn more about how you structure code. What does a project structure look like for you? I usually conceptually try to separate the view and data starting with the simplest file structure and dividing as needed.
gregkerzhner 5y ago
How do you manage data flow from your view layer to your API layer? Like for example, if a UITableViewCell has a button in it which needs to load some data from the API? Do use an event/delegate which flows from the UITableViewCell through the `cellForRowAtIndexPath` method to the controller, out to some other class? It must feel pretty great to have your business logic and API layers abstracted into other classes, and have your lean view controller just be the glue. Yay MVC! Now imagine that your table view has 20 cells, and each cell is managed by a team of 5 people and needs 1,000 lines of code to fulfill its business logic. How would this approach hold up? Would you have all 100 people working on the same `cellForRowAtIndexPath` method, piping every event for those 20,000 lines of code through there? When people talk about scale on iOS, they are talking about potentially 100s of people working on the same screen. With something like React, this is trivial by having each team work independently on its own components. With iOS, its much harder out of the box.
- 3grdlurker 5y ago
  > business logic and API layers abstracted into other classes, and have your lean view controller just be the glue That’s pretty much the technique. :) Also, composition by child view controllers.

gregkerzhner 5y ago

I fully agree here - MVC scales terribly. Of course, it's not impossible to come up with a well designed MVC app at scale, but it takes a ton of skill and feels like you are fighting the framework at most steps. One particular challenge is lack of modular components and component nesting. For example, if you have a list view, it's very natural to have one component define the list, and child components define each entry in the list. Something like React makes this trivial. On iOS on the other hand, you are encouraged to use a UITableViewController with UIViews for each cell. This immediately pushes you towards one mega-controller which mixes the responsibilities of the list with those of the individual cells. To overcome this, you could try to have a UIViewController for each cell (uncommon), or have the UIView of each cell start taking on more responsibilities of a UIViewController (breaking MVC). In general though, iOS's MVC is a perfect storm of being both bare bones as well as opinionated at the same time. For these reasons many large corporations have moved away from MVC to their own custom in-house architectures to handle scale. Facebook - https://www.youtube.com/watch?v=mLSeEoC6GjU https://www.youtube.com/watch?v=mLSeEoC6GjU. * Uber - https://github.com/uber/RIBs https://github.com/uber/RIBs * Square - https://github.com/square/workflow https://github.com/square/workflow

ardit33 5y ago

Do you realize that the whole Apple's UIKit Framework is a version of MVC? I have seen many versions for it in iOS, MMVC, MVVC, or whatever, but really they are iterations of separation of business logic and view/display logic. You can disperse the view logic, without having traditional centralized controllers, but your business logic will end up centralized in one place. So, in practice you end up with a Model-Business-Logic / View paradigm, where traditional controllers end up just being a thin layer. Protocol driven development, reminds me the old Java style of having a class (eg. MyFunctionalityClass), which was either abstract, or had only protocols declared, then have another MyFunctionalityClassImpl to actually implement it. I didn't think it was pretty, and it seemed it was done by C++ developers to simulate the lack for header .h files in Java. Ps. Before you reply on a ad-hominen way, I probably have much more iOS experience than you, since I both have worked on it since day one, and have worked on some the currently largest apps in the world.

swiftaccount1 5y ago
I basically agree with you, actually. It feels like a lot of this is breaking down into semantics. I’m not fond of acronyms, I believe it’s important to go to core principles and never do anything blindly, but only when it’s useful. The fundamental challenge of iOS architecture is picking the right level of abstraction for the complexity of your application. The trouble that comes in with MVC, as I see it, is how easy it is to shoot yourself in the foot. It’s too easy to do it “wrong”, which is why so many have tried to come up with something different. Of course you can’t escape the MVC-ness of the platform, it’s all about how you manage it.