That was my fear while I was writing the post :\

The problem with Rx / RAC is there's a big learning curve, especially coming from procedural programming. It's much bigger than 1 blog post can cover. My hope at least is that it will drive at least some people to dive deeper.

Yeah, we played around with a bunch of different styles, including defining the block before its use. It looked cleaner but the code locality of defining them inline won.

I'd love to do this. The hard part is getting Xcode to cooperate :\

We have a bunch of topic- or project-specific rooms, one room for animated gifs and pictures of cats, and one room for serious business stuff.

Pretty much everybody hangs out in the cat picture room and serious room. The rest are just people interested in that topic.

It was intentional. There are differences between the 32- and 64-bit ABIs that make life easier for us to go 64-bit only.

Fair enough, I'd probably do the same if I wasn't a CoreDuo owner myself, especially since Lion's dropping support too.

Yes. But the update experience for Mac App Store apps is so bad right now that it's a bit discouraging.

What about the update experience do you find so bad/discouraging?

It takes days/weeks for Apple to approve updates and then users have to consciously open the Mac App Store app and download them.

It makes me really sad that for a lot of people John Locke == some dude from some shitty show.

AppKit and UIKit aren't at all similar. And they aren't related. UIKit was written from the ground up for iOS and is based on Core Animation. AppKit was written by NeXSTEP and is based on software rendering with dirty rects.

This argument seems strange to me.

UIKit was written, from the ground up, by people who either worked on AppKit or worked with AppKit, with full access to the AppKit source base. They share almost all design patterns, and some source code. UIKit is clearly based on AppKit.

Pervasive use of layers is indeed a difference. That's hardly the only thing interesting about either framework, though.

Compare NSView vs. UIView. Or NSViewController vs. UIViewController. Or NSTableView vs. UITableView. NSButton vs. UIButton. Same names but very different design patterns and APIs.

I've worked on many iOS and Mac apps. I'm honestly not sure how anyone can claim AppKit and UIKit are essentially the same.

What would you consider the essential Cocoa design patterns? I would point at the items listed at http://developer.apple.com/library/ios/#documentation/Cocoa/... . Delegation, notification, target action, the responder chain - these are all shared.

The frameworks are not identical, but to say they're not related… they only look wildly different if you're focusing in incredibly closely. If you consider .Net, or Java, or Rails, or GTK, or almost anything else, the differences between AppKit and UIKit are miniscule.

Nobody is saying that that they're not related. They clearly are (although the presence of other UI libraries does not affect any comparison of that relationship at all.

Your examples of delegates, responders, targets etc are concepts - and indeed UIKit and AppKit are both built around the same concepts.

The implementations of both is quite different however, to the point that porting something of complexity from UIKit to AppKit involves a lot of tedious changes - or worse: creation of abstraction layers if the codebase is to be maintained for both apps.

> AppKit and UIKit aren't at all similar. And they aren't related.

Actually, they're incredibly similar in terms of class hierarchy, design patterns (e.g., delegates, data sources, target/action for the most part), graphics principles (points vs pixels), use of various Foundation and CoreGraphics data structures, etc.

And yes, Core Animation works quite well with layer-backed views in AppKit, which is where it started.

It's easy to point out specific differences between these frameworks, but I think any developer who's already learned one would object to the underestimation of his/her intelligence that would be implied by comparing the subsequent difficulty in moving to the other with that of any other non-Apple platform SDK.

Perhaps you'd like to point out another SDK that is more similar to AppKit than UIKit?

Sure but it's all in how you use it. Not everything comes over cleanly but a lot does. AppKit is old and crufty and doesn't play well with Core Animation. Since Chameleon is Core Animation-based, it's already off to a better start than AppKit.

But AppKit is pretty awful. I'm much more interested in Chameleon as a Core Animation-based replacement for AppKit than as an easy way to port iOS apps.