ReactiveCocoa & Friends
I've been playing around with ReactiveCocoa lately, and I think it's really neat. I sorta diffusely worry about its debuggability, but I haven't hit a wall in that regard yet. The memory management is mind-bending, but it seems that they have it nailed (at least, I haven't been able to make it visibly leak yet.) It's been fun to play around with, and I feel like it takes a lot of the pain out of KVO. (I really wish Apple would build and distribute a sanctioned, blocks-based overlay for KVO, but that's another rant.) I also appreciate the more functional handling of sequences/collections/etc in ReactiveCocoa.
I subsequently saw that these guys have a spinoff project called ReactiveCocoaLayout. I played with it for about half an hour, and I rapidly came to the conclusion that this solution is way worse than the problem it seeks to solve. No one can deny that the current state of AutoLayout in Xcode/IB is pretty unfortunate, but at it's core, I think Cocoa AutoLayout is pretty sound, and a real improvement over struts-and-springs layout. Since ReactiveCocoaLayout demands that you do all your view management and layout in code, I can't, in the context of this discussion, hold the state of Xcode/IB's AutoLayout support against it; If you drop IB and do all your views in code with Cocoa AutoLayout, the world is about as nice a place as it could be, considering that you've abandoned all visual tools.
The main feature of ReactiveCocoaLayout, according to their readme seems to be that it's linear, progressive and top-down (unless you specifically make it bi-directional.) I'll be the first to admit that AutoLayout's linear-programming-based, simultaneous-solving characteristic can be hard to get your head around, but I think the answer there is better documentation and better tools, not a wholesale new approach. (Personally, my wish for AutoLayout docs would be for about a dozen non-trivial examples, with detailed view-by-view, constraint-by-constraint explanations addressing (across multiple examples would be fine) all the different priority ranges, as well as compression resistance and hugging priority.)
When considering any of new approach like AutoLayout or ReactiveCocoaLayout, I ask myself: Does this make the problem space more understandable? The code more succinct? More performant? I think the answers for ReactiveCocoaLayout, so far at least, are, "No", "a BIG No", and "looks like No, but I haven't put the screws to it." I get the argument that the linear, top-down progression is a feature, but since there's (AFAIK) no native debugger support for "step down this signal chain" without stepping through oodles of framework code a lot of this is either lost or relegated to NSLog-based debugging.
IMO, what ReactiveCocoaLayout would need to get traction is a specification syntax as simple as NSLayoutConstraint's. I won't go so far as to say it should be as "simple" as NSLayoutConstraint's visual format syntax (because I think that particular feature is a "neat hack" but not quite worth it.) At the very least, they need an API like: +[NSLayoutConstraint constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:] with slight adjustments to encapsulate the linear, top-down-ness of it. But from a succinctness perspective, they need something at least that succinct, if not more so. One look at the ResizingWindow demo, and it's patently obvious -- RCL doesn't even begin to compete for readability and succinctness with Cocoa AutoLayout.
If you're a functional-programming-minded person, I encourage you to take a look at ReactiveCocoa. Maybe they'll get there with ReactiveCocoaLayout, but for now, I'd suggest continuing with Cocoa AutoLayout. I'm optimistic for what we'll see out of WWDC too.
I subsequently saw that these guys have a spinoff project called ReactiveCocoaLayout. I played with it for about half an hour, and I rapidly came to the conclusion that this solution is way worse than the problem it seeks to solve. No one can deny that the current state of AutoLayout in Xcode/IB is pretty unfortunate, but at it's core, I think Cocoa AutoLayout is pretty sound, and a real improvement over struts-and-springs layout. Since ReactiveCocoaLayout demands that you do all your view management and layout in code, I can't, in the context of this discussion, hold the state of Xcode/IB's AutoLayout support against it; If you drop IB and do all your views in code with Cocoa AutoLayout, the world is about as nice a place as it could be, considering that you've abandoned all visual tools.
The main feature of ReactiveCocoaLayout, according to their readme seems to be that it's linear, progressive and top-down (unless you specifically make it bi-directional.) I'll be the first to admit that AutoLayout's linear-programming-based, simultaneous-solving characteristic can be hard to get your head around, but I think the answer there is better documentation and better tools, not a wholesale new approach. (Personally, my wish for AutoLayout docs would be for about a dozen non-trivial examples, with detailed view-by-view, constraint-by-constraint explanations addressing (across multiple examples would be fine) all the different priority ranges, as well as compression resistance and hugging priority.)
When considering any of new approach like AutoLayout or ReactiveCocoaLayout, I ask myself: Does this make the problem space more understandable? The code more succinct? More performant? I think the answers for ReactiveCocoaLayout, so far at least, are, "No", "a BIG No", and "looks like No, but I haven't put the screws to it." I get the argument that the linear, top-down progression is a feature, but since there's (AFAIK) no native debugger support for "step down this signal chain" without stepping through oodles of framework code a lot of this is either lost or relegated to NSLog-based debugging.
IMO, what ReactiveCocoaLayout would need to get traction is a specification syntax as simple as NSLayoutConstraint's. I won't go so far as to say it should be as "simple" as NSLayoutConstraint's visual format syntax (because I think that particular feature is a "neat hack" but not quite worth it.) At the very least, they need an API like: +[NSLayoutConstraint constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:] with slight adjustments to encapsulate the linear, top-down-ness of it. But from a succinctness perspective, they need something at least that succinct, if not more so. One look at the ResizingWindow demo, and it's patently obvious -- RCL doesn't even begin to compete for readability and succinctness with Cocoa AutoLayout.
If you're a functional-programming-minded person, I encourage you to take a look at ReactiveCocoa. Maybe they'll get there with ReactiveCocoaLayout, but for now, I'd suggest continuing with Cocoa AutoLayout. I'm optimistic for what we'll see out of WWDC too.