This is a good thing. While very similar, UIKit blows AppKit away in terms of API usability and design. Also, I think it's perfectly fine to write macOS apps using UIKit, would be similar to making iPad apps. It needs a few Desktop/Mouse related adjustments but Apple is probably going to be smart about that.

Definitely not gonna be like what happened with Windows Metro apps

I agree, and frankly it’s been obvious since its inception that uikit is a better appkit written with the benefit of experience - more limited at present but suitable for all devices. They should have started this years ago and have a unified platform with tweaks for different UI.

Bizarre doublespeak in the presentation though as they denied this was the plan - explicitly said no merger.

It's not doublespeak, it's very clear refutation to those who fear macOS fading away and being replaced by a locked down, ARM-powered iOS laptops, Apple machines turning into alternate version of Chromebooks. The message reads to me as "we're bringing the good things from iOS over to macOS, rather than abandoning macOS and replacing it with iOS".

> It's crazy to develop very similar APIs for GUI apps in parallel, and what has become two different OSs with slightly different apps and feature sets, but a huge amount of overlap. The savings for Apple and developers of having a consistent set of new APIs and one set of apps to manage (for example their entire office suite) would be huge.

Right, and what the announcement seems to show is that UIKit could eventually grow to replace AppKit. Like you yourself say - "uikit is a better appkit written with the benefit of experience".

That still doesn't imply the two OS would necessarily be merged - there's still a ton of things that make sense for macOS that are not needed in iOS, and vice versa - just for one thing, they have vastly different energy budgets. There's also a ton of overlap and shared code already, for pieces that it does make sense to share.

So, I still think the answer is really targeted at people who fear that iOS (with all of its current limitations) will replace macOS, essentially, rather than being a misdirection as you seem to find it?

From a customer perspective, there may be two OSs - that's really a marketing question.

From a developer perspective, I expect them to arrive at one API, with a few options to allow feedback from various sources (tap or click), and handling multiple screen sizes gracefully, and therefore pretty much one OS, so that you can build one app across devices - this is exactly what they are trying out with their ios app port. Once you do that, it doesn't make sense to have two APIs.

I can't think of many features that would be exclusive - to take your example of energy budgets, saving energy on both is equally important now that laptops are a mainstay and desktops an afterthought. We may well see ARM laptops for this reason. Watches are the one exception that have a budget so tight at present that normal apps just aren't feasible.

So I think a merge is exactly what is on the cards in the long term, particularly as they are now run by an operations person and the money flows in more and more from phones, not computers.

Hope significant are the differences between cocoa and uikit? I don't have any experience besides some light source browsing and it seemed the big difference is the NS to UI prefix change. Anyone care to summarize for the unenlightened?

The differences are more in implementation than anything else:

- AppKit isn't layer-backed by default, requiring you to handle this. Something as simple as setting the background color for an NSView is far more of a ritual than it is for a UIView.

- NSColor/NSImage under the hood are different than UIColor and UIImage.

- NSTableView and NSCollectionView have big differences (NSCollectionView is more subtle, I should say) that rear their head when you start trying to do anything like you would on iOS. e.g, NSTableView doesn't automatically get an NSScrollView, grouped rows operate like headers but the underlying data structure isn't easy to share, collection view items are view controllers on macOS but not on iOS, etc.

- Delegate methods are entirely different, requiring you to #if check everywhere.

- Trying to use NSTextField like a UILabel is a trip, requiring you to understand an archaic NSCell architecture that you'll wish you didn't have to deal with in 2018.

The list goes on, and most developers that share code between iOS and macOS have their own frankenstein framework floating around. UIKit on macOS would do a lot to alleviate this.

Edited because, speaking of 2018... this should not be this annoying to format.

Similar to some markdown parsers, you need to have multiple newlines in the source in order for the presentation to have a newline.

EDIT: Looks like you got there before I finished typing.

I prefer working with UIKit too, but there are reasons for some of the differences. Jeff Nadeau, an AppKit engineer, wrote a bit about them a couple of weeks ago: https://gist.github.com/jnadeau/9321a22b19301215e25401ffd1f1...

Yup, I follow him on Twitter. :)

Regardless of how correct he probably is, the fact of the matter is that there's overwhelmingly more developers on the UIKit side and that API is what people clearly prefer - the only ones voicing otherwise are old Cocoa-heads. It's ridiculous that it's 10 years later and Apple is only now confronting this.

Also, just to follow up on my original comment... from what I saw over on Twitter, 10.14 finally implicitly layer-backs apps by default, so the first point becomes much less of a nuisance than it used to be. Apps have to be linked against 10.4, mind you, but yeah.

Props to Apple for finally fixing it.

"Something as simple as setting the background color for an NSView is far more of a ritual than it is for a UIView."

Or you just use an NSBox as the rearmost subview of the NSView, and set its fill color.

I suspect that is exactly the kind of ritual he was talking about.

Not much of a ritual, really. Couple lines of code. Just a common case of using a UI widget in a way that isn't really done on UIKit.

So is the half-assed approach of working with the layer background. ;P

That's what a ritual is; it's 2018 and I should not have to go out of my way to set a damn background color on a view. UIView has predictable behavior, AppKit does not.

Yuuuuup.

Cocoa developers tend to think it's all very apparent though. Was actually counting down until a comment like that appeared. ¯\_(ツ)_/¯

Cocoa bindings in UIKit would be nice to see.