Re:SwiftUI and Catalyst: Apple executes its invisible transi...
by tinus_hn on Friday June 14, 2019 @05:00AM
(#20181473)
I would say the invisible strategy here is to move away and ultimately deprecate AppKit because it carries decades of legacy compatibility and is limited by being bound to Objective C, while clearly Apples vision is that the future is Swift.
Re:SwiftUI and Catalyst: Apple executes its invisible transi...
by setpatchaddress on Thursday June 13, 2019 @11:46PM
(#20180449)
Carbon.
Re:SwiftUI and Catalyst: Apple executes its invisible transi...
by diesal11 on Friday June 14, 2019 @12:06AM
(#20180506)
Has been deprecated since 10.8 (2012) and was never ported to 64 Bit. It was pretty clear they weren't working on a Carbon replacement imo.
Re:SwiftUI and Catalyst: Apple executes its invisible transi...
by stefanfisk on Friday June 14, 2019 @11:50AM
(#20183945)
True, but the official deprecation was quite sudden, and anyone using at the time and who expected Apple to be open and sensible about their API direction was caught quite off guard.
Apple has never described Swift, Catalyst, or SwiftUI as a transition from or to anything. Instead, Apple has gone out of its way to say that these are not transitions. Remember that big "NO" slide from last year?
When a transition is required, Apple does not ever hide it.
Classic Mac to OS X was a transition.
PPC to Intel was a transition.
UIWebView to WKWebView is a transition.
SwiftUI is no more a transition from AppKit/UIKit than Storyboards were a transition from NIBs and programmatic UI.
Modern ObjC syntax, Enterprise Objects, Java/Cocoa Bridge, Ruby/Cocoa, Python/Cocoa, Key-Value Observing/Encoding, ObjC Garbage Collection, ARC, Storyboards, Playgrounds, Swift, SwiftUI, etc. These are not transitions. These are all just tools in the toolbox. Some more useful than others.
The only thing Apple's engineers are trying to do here is create stuff that developers find useful. There is no hidden or invisible strategy with this stuff.