[TzlZAT8GSEDww00]

> Now that Swift is open-sourced, I wonder if we'll see a good Cocoa port to Win32 and Linux - because that would be NEXTSTEP's legacy.

Never say never, but none of the UI parts of Cocoa are written in Swift, and porting them to Windows/Linux would be way more than just writing them in Swift anyway.

Curious, in what way is Windows's development story stuck in 2005 and the Mac is not similarly "stuck" in 2001 (or perhaps 1995)?

[DaiPlusPlus]

Apple pretty much said that Cocoa would be the basis for all future work they do on Mac OS X since 2001, and they've continually improved it, such as adding new widgets, adding functionality to existing widgets, high-DPI support, and so on. I see there's a lot of DRY (Don't Repeat Yourself) going on: there is only one GUI platform and UI toolkit for macOS: Cocoa. While the groundwork isn't new it is kept up-to-date.

Compared to Windows where the "original" widget-toolkit (Window classes and the Common Control library) haven't been significantly updated since Windows XP - Wndows 7 did add some new controls, but they aren't exactly easy to use unless you're already a very experienced C++ Win32 GUI developer.

The old low-entry-barrier dev story was VB6, which had a mix of Common Controls and ActiveX reimplementations, then it moved over to VB.NET and WinForms, which is a wrapper around the same - but the last significant update to WinForms was in .NET 2.0 in 2005 - Microsoft recently announced that they would not be adding true high-DPI support to WinForms, advising desktop app developers to use WPF or UWP instead - and therein lies a problem: WPF and UWP are both completely separate UI and application stacks. WPF is not perfect and like WinForms, hasn't seen much of an update for a while (it still runs on DirectX 9) and UWP is just confusing: it's arbitrarily limited to only run in a restricted sandbox environment, the standard widget library is very anemic (e.g. still no tree-view!) and it shares nothing in common with the rest of the entire Windows ecosystem.

If you want to write a "real" Win32 desktop application you're best-off sticking with MFC, but there's so much legwork that's necessary, and legacy cruft (I swear the MFC codebase is still C++89 compatible) it just doesn't make sense for small applications, especially line-of-business systems that face constant changes, to be built with it. Compare with Cocoa on macOS where everything: from Microsoft Office and Adobe Photoshop, to the built-in Jigsaw Puzzle mini-game, is all built with the same framework.

[ams6110]

The port was already done in the 1990s. You could run Enterprise WebObjects on Windows NT, and it came with several NeXTStep apps on the CD including Mail.app.