3

I've been trying to wrap my head around the MVC design pattern, Apple's view of it and that of a whole bunch of JavaScript frameworks.

So there is model to represent the data, view for user to interface the app. And then there is controller, being mostly the glue between the other two.

Apple's Cocoa seems all about MVC as far as UI is concerned, and somewhere along the years of its existence Cocoa Bindings were introduced with the promise to reduce the glue code amounts.

Then Cocoa Touch came along, but without Bindings.

My question is to those familiar with both Cocoa and Cocoa Touch: was there a reason to omit this supposedly great glue-code saver from this newer Cocoa incarnation?

Admittedly, mobile UI is very different from its desktop counterpart, but could it be that the whole value of Bindings was proven insignificant? Benefits not worth the porting-to-UIKit effort? Somewhere on the web (Wikipedia?) it says that Microsoft's MVVM's first critic was its creator.

It's hard to believe Apple would leave the whole world of iOS apps developers to solve the same glue-code task instead of solving it once on the SDK level.

tereško
  • 58,060
  • 25
  • 98
  • 150
Srg
  • 510
  • 4
  • 13
  • There is this closed question: http://stackoverflow.com/questions/4706247/is-there-any-technical-conceptual-reason-why-ios-does-not-support-cocoa-bindings , but the answer doesn't sound all that plausible to me. – stevesliva May 01 '14 at 15:46
  • @tereško the question is more about MVC and pattern like Bindings rather than Apple's view of it in Cocoa. – Srg May 01 '14 at 20:02
  • I couldn't believe it either, didn't find a good answer, then I wrote [AKA Beacon](https://github.com/mutech/aka-ios-beacon). It's not quite as good as something natively provided, but it works pretty well and doesn't feel much different from using XAML or Knockout. – Michael Nov 30 '15 at 02:23

0 Answers0