Hacker News new | ask | show | jobs
by kmeisthax 1571 days ago
Furthermore... how would one even remove Objective-C? It's the glue that holds everything together in macOS[0]; removing it would be like removing COM from Windows. Apple would need to rewrite all of their public frameworks in Swift and remove the Objective-C bridges... and, at that point, why stop at just removing Objective-C? Why not kill AppKit while we're at it and make UIKit the only way to present a window[1] to the display? At that point, nobody is going to bother rewriting their apps[2], and the Mac loses all it's developer support.

[0] And, for that matter, most of their other operating systems.

[1] WindowScene, technically

[2] Astute fans of macOS history might remember this sounding quite familiar. When Steve Jobs bought Apple with Apple's money, he wanted to basically continue NeXT as it was (even the Windows NT port) and replace System 7 entirely with lightly-rebranded OPENSTEP 5 and a VM (dubbed the "penalty box"). This failed so dramatically the whole project was cancelled/rebranded as "OSX Server", and Apple announced Carbon to provide Classic APIs with minimal changes on OSX.

1 comments

Furthermore, like COM is pretty much alive (thanks WinDev), some newer Apple frameworks like Metal are actually written in Objective-C (with C++ for the shaders), Swift API for Metal are just bindings.

Regarding point 2, that was thanks to Adobe and Microsoft pressure to keep targeting Mac platforms. Sean Parent from Adobe / C++ fame was a key person in this process.

Also, as much as Apple gets a rep for putting developers on an upgrade treadmill and breaking old apps, they actually aren't the worst offenders. Their internal rule is "don't break existing APIs without a good reason", and that's something they learned from the Rhapsody dustup[0]. You can contrast this with Microsoft and Google, who follow opposing philosophies:

- Microsoft: Don't break existing APIs, period. If the existing one can't be extended, write an entirely new system to replace it (e.g. XAML, UWP XAML) and leave the old system in the OS forever.

- Google[1]: Don't complicate your code with backwards compatibility. If some change would make the code better, scan the entire Google monorepo and recompile the world against your new version, and then tell our AppEngine customers they have about a week to transition.

[0] Carbon wasn't deprecated until 64-bit Intel support happened, and was only removed alongside 32-bit Intel support. A Carbon universal binary can target a disturbingly large range of macOS versions - basically Mac OS 8 up until macOS Catalina.

[1] Mercifully, the Chromium and Android teams actually don't buy into this.