The user interface elements in MacOS are supplied by AppKit, in iOS it's UIKit. What I expect to see is a marriage of the two with AppKit perhaps reimplemented

The user interface elements in MacOS are supplied by AppKit, in iOS it's UIKit. What I expect to see is a marriage of the two with AppKit perhaps reimplemented with UIKit classes. Fracturing UIKit isn't unprecedented, it's already done on iOS with the iPad having widgets and features not available on iPhone. UIKit is cleaner having been redesigned after so many years and with so many other technologies baked (CGLayer & CoreAnimation for example). AppKit would continue to exist for some time with developers having the option of mixing the two (as not all features will be available at the UIKit layer to start.) A good example of where UIKit bests AppKit is the seemingly simple "Put an animated progress meter in a table row". This is easy in UIKit because table cells are UIViews. However, in AppKit, a table cell is a NSCell which is -not- a view. On MacOS nearly everything has a NSView and a NSCell component (i.e. NSButton, NSButtonCell) On iOS there are no cells. (UIButton, no UIButtonCell.) Other AppKit classes will be implemented using their UIKit counterparts (NSView to UIView, NSWindow to UIWindow). The result will be a much cleaner development environment for applications that favors animation, multi-touch, and code reuse with the iOS platform.