* Constantly changing APIs based on Microsofts internal politics vs. the very stable Cocoa
Really? I can run Windows apps I bought 10 years ago easily, whereas many Mac apps seem to break with every OS update. It's also extremely hard to build apps for older versions of Mac OS X, as Apple hide the older versions of the SDK.
I think m_mueller's comment is more from a developer's perspective than a users. Microsoft has done an amazing job of preserving compatibility. Its not that Microsoft gets rid of APIs (they don't), but that they haven't stuck with a "one true" API to program Windows in[1]. Their switching of what tech you should use to build your apps is problematic.
Cocoa has been a long path, but my Windows friends have had a constant churn of the latest API to use.
1) I am talking about the stuff we are supposed to use above the base Win32.
A key difference with the Microsoft approach vs the Apple approach is that on Windows the API that exposes every single feature is such a beast that developers are expected to work at a level above that API.
Whether it's WPF, WinForms, WinRT, or whatever the new flavour of the day is, it's always a layer on top. And that layer is never perfect, because you still have to do the occasional [DllImport("Kernel32.dll")] interop reference.
Here are the currently supported ways to deal with windows on Windows:
* HWND
* System.Windows.Window
* Windows.UI.Xaml.Window
On OSX, you use Cocoa. When Apple introduced Swift, they didn't have to layer on top of the API accessed by ObjC. When you write Swift code, you call the exact same APIs as you would have done with your ObjC code.
Here are the currently supported ways to deal with windows on the Mac:
Sure, but the Windows APIs that I mentioned aren't historical. Those are all currently supported APIs. Carbon/Cocoa was the last time that OS X has had a dual-API situation but even then, Carbon was always referred to as the transitional library and Cocoa was always referred to as what you should use for new code.
While Apple floundered during the 90s with their OS strategy, their API strategy in OS X has been absolutely rock solid.
It's now 2016, Carbon has come and gone as it was intended to and Cocoa is still around and is still the API you use for working with the Mac. If you're trying to do something on the Mac, there's going to be a single officially supported way to do it and that's it (if it's supported at all).
Meanwhile, there are three totally different frameworks on Windows that you can use to do the same thing, all of which are officially supported and none of which are deprecated.
> It's now 2016, Carbon has come and gone as it was intended to and Cocoa is still around and is still the API you use for working with the Mac. If you're trying to do something on the Mac, there's going to be a single officially supported way to do it and that's it (if it's supported at all).
There are quite a few 32bit apps making use of it and they will never be ported to Cocoa.
> Meanwhile, there are three totally different frameworks on Windows that you can use to do the same thing, all of which are officially supported and none of which are deprecated.
Win32 and MFC are deprecated for new applications, the way forward is UWP with XAML.
Project Centipede is just for porting existing code into UWP world.
Windows Forms was officially deprecated at BUILD 2014.
> Sure, but the Windows APIs that I mentioned aren't historical. Those are all currently supported APIs.
That's not a bad thing. It means if I wrote an app 5, or 10, or 15 years ago, I can keep working on it and updating it without having to throw most of the code away and start again.
Really? I can run Windows apps I bought 10 years ago easily, whereas many Mac apps seem to break with every OS update. It's also extremely hard to build apps for older versions of Mac OS X, as Apple hide the older versions of the SDK.