I don't really understand his complaints about the lack of compatibility between traditional Cocoa (i.e. Foundation+AppKit) and Cocoa Touch (Foundation+UIKit).
I've been working with Cocoa for years. It took me just an afternoon to port a graphics and audio application from Mac OS X to Cocoa Touch. Granted, it's a pretty simple application [1] designed for maximum cross-platform compatibility by being written in C. But jwz's Dali Clock is even simpler with the same portability goal...
In my experience the changes made in UIKit are perfectly reasonable given the constraints of the platform. In many places Apple has managed to substantially improve the experience of mixing plain-C CoreFoundation and Obj-C Cocoa by lowering the historical "impedance mismatch" between the two that still persists in AppKit. There's nothing wrong with doing an API cleanup when the opportunity for a break with the past presents itself.
His initial goal was to not have to port it -- it was to get it compiling from the same source on both, since they're both Objective-C applications written atop OS X.
What he found was that similar functionality was implemented with an arbitrarily different interface. UIKit is not exactly the same as AppKit (I think it's a little bit cleaner) and breaks AppKit code even for features that are supported on both sides.
If you're used to stable APIs and expect strong justification for changing an interface, especially when there is no apparent change for features supported or efficiency, going from AppKit to UIKit is like having someone flick vinegar off of their finger tips into your eyes.
And if you're used to being able to develop software (using other open source software) on a computer you paid for and run it on a device you paid for without having to pay again and sign a contract limiting your freedom, then it's like getting a right hook to the abdomen.
IMHO, moving from a 23" screen and multi-GB memory to a 3.5" screen and 128 MB is strong justification for changing an interface.
Most of AppKit just doesn't make any sense in a single-task, single-window system. They could have kept some of the classes, but what would be the point? A tiny minority of Mac apps are as simple as jwz's clock. Everything else would need rewriting anyway.
I've been working with Cocoa for years. It took me just an afternoon to port a graphics and audio application from Mac OS X to Cocoa Touch. Granted, it's a pretty simple application [1] designed for maximum cross-platform compatibility by being written in C. But jwz's Dali Clock is even simpler with the same portability goal...
In my experience the changes made in UIKit are perfectly reasonable given the constraints of the platform. In many places Apple has managed to substantially improve the experience of mixing plain-C CoreFoundation and Obj-C Cocoa by lowering the historical "impedance mismatch" between the two that still persists in AppKit. There's nothing wrong with doing an API cleanup when the opportunity for a break with the past presents itself.
[1] http://lacquer.fi/2020