I am not too sure about the fundamental difference between Cocoa Bindings and IBOutlets/IBActions. I am currently migrating an Obj-C project to Swift 3 and I want to know whether it is common practice to use bindings, especially in Swift? There is very little community discussion on bindings in general and I am CS student new to Cocoa/CocoaTouch dev, so I would appreciate verbose answers.
-
On OS X, Cocoa Bindings are the same in Swift as in ObjC. For iOS, don't use bindings with UIKit controls because [they are not KVO compliant](https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/KVO.html) – Code Different Jun 28 '16 at 17:29
-
@CodeDifferent Even on OS X binding on a view is often possible and rarely useful, it is anticonceptual to bind on a view. – Amin Negm-Awad Jun 28 '16 at 17:51
-
1@AminNegm-Awad I find binding to be extremely useful and cut down a lot of code, particularly if the app is data-intensive. When it works, it does seem magical. The trick is to get it right because wrong bindings are hard to debug. There's nothing anticonceptual about it – Code Different Jun 28 '16 at 17:58
-
1I did *not* say, that is is not useful. I said that binding on a view (not: binding a view) is anticonceptual. However, it isn't magical, but late binding. It is Obj-C at its full strength. (Okay, the dynamism of Obj-C has magical power as you can see here, but in nowadays some people forget about that and develop funny languages, in which you cannot write big parts of Cocoa. But the first people recognize that. Ask a guy at UIKit team. I call it "With a little help of my Objective-C friends" Swift is a programming language you can use, if you have to. Doing it voluntary is akin of masochism.) – Amin Negm-Awad Jun 28 '16 at 19:04
1 Answers
First of all Cocoa bindings are not supported by Cocoa Touch, but solely by Cocoa. Since the focus of software development went to mobile devices, Cocoa bindings became less famous. However, you can implement bindings on top of key-value observation. The question is, whether it is worth. The big deal is key-value observing.
Additionally Cocoa bindings are an implementation of reactive programming. On a mobile platform the pressure to do so is less than on a desktop, because the UI is "more modal".
In relation to Swift, it would be impossible to implement KVO and Cocoa bindings without special language features and the dynamic runtime environment of Objective-C. There are classes created at runtime, selectors build from strings and so on. All the dynamic stuff Swift hates and tries to make unnecessary. So you can call it "unswifty". However, it is a living part of Cocoa and beside ideological reason I do not see, why you should relinquish it.

- 16,582
- 3
- 35
- 50
-
One issue I noticed is that if youre coming in with only a Swift background, the key paths might not be what you expect. E.g. the Swift interface of `NSSpplitViewItem` shows that it has a boolean property `isCollapsed`. But using that as the key path wouldn't work. The actual key path is the Objective C one, `collapsed` – Alexander Sep 08 '17 at 16:25