The WWDC 2019 had a major impact on the UI toolkit landscape: while the venerable AppKit APIs remained available, Apple removed the old Carbon APIs and introduced 2 brand new frameworks: Mac Catalyst and SwiftUI.
Apple sporadically mentioned some apps built with these new UI toolkits. In this article, I try to bring a better overview of Apple’s use of AppKit, Mac Catalyst and SwiftUI in the different versions of macOS, from macOS Mojave to macOS Ventura.
Really great visualisation, and shows that the march to SwiftUI continues – however, I’m not entirely sure macOS users should be happy about that.
Ugh. Why are all vendors so obsessed with replacing battle-tested UI toolkits with buggy new stuff? It’s CADT without GNOME.
In the case of SwiftUI, we talking about a new programming language that’s a lot easier to use for most developers than Objective-C, and a UI framework built for the idioms of that language as well as making use of declarative UI definition idioms, arguably the easiest, most efficient way that has been invented so far to define UIs. Altogether this equals a serious gain in developer productivity, as well as a lower barrier to entry for developers new to the platform. In this particular case I absolutely laud Apple for what they are doing, and imagine it is benefiting their internal development enormously as well.
And yet somehow PyQt and PySide don’t induce bugs in Qt like that, because, despite Qt being written in C++ and your code being in Python, all the battle-tested code for things like “Should something misbehave if you scroll it like that?” or “Should a button break down if you nag it too many times?” is reused C++ code paths.
I don’t know what caused the arrow up bug on the linked video, but 1) it’s not really a big deal Imho and 2) without seeing the source code there’s really no saying whether this bug has anything to do with the UI framework as opposed to say, simply being the kind of thing that happens when you rewrite an app.
Suit yourself. I actually like having a GUI that doesn’t feel like every papercut bug will be answered with “it’s not a big deal”. Being surrounded by rickety interfaces wears on you.
Both of those bugs are things which would be vanishingly unlikely in a Qt+binding situation because rewriting the app wouldn’t rewrite the relevant code.
Once you’ve done the initialization of the widgets (eg. called the method to set an icon on the button), that functionality is handled entirely in the battle-tested toolkit code, not the application layer.
(Unless you go out of your way to write something unidiomatic that does something crazy like resetting the icon on the button with every click.)
It’s more than just the one video, read the whole thread. Lots of really weird UI stuff going on that should never be seen by a macOS user. It’s reminiscent of early GNOME3 crap, and does not belong in a commercial OS. Even Microsoft is doing slightly better with their still mixed-bag of Windows 7 era controls popping up when you dig deep into Windows 11; it’s out of place but at least it’s functional. There are completely hidden buttons and unscrollable lists in the examples from the linked Twitter thread. That’s unacceptable.
It’s sad to see that the Reality Distortion Field is still alive and well in some people…
Swift is not necessarily an improvement over Objective-C, and SwiftUI is most definitely not an improvement over Interface Builder. I guess if your goal is to attract bottom of the barrel programmers, then your what you’re saying might be true. But even if that’s the goal, I’m not sure your statements hold true.
The power of NeXT, Yellow Box, OS X and now macOS has always been Interface Builder and the OPENSTEP/Cocoa frameworks. Attempting to throw those out will most certainly end in tears.
Swift (at least before it got incredibly complicated) was a relatively clean win over Objective-C in many ways. I mean, using vtable calls to methods is measurably faster than obj message sends, and Swift’s encouragement to avoid object hierarchies altogether is more performant still. That Swift lately has gotten so complicated that its inventor Christ Lattner doesn’t want to work on it anymore (goest against his original vision) is quite worrying though.
As for SwiftUI. I think it’s pretty clear at this point that a more reactive approach to UI is a part of our future (or even present), but it’s also clear that we just don’t know the best to do it yet. Should it always have an exposed imperative layer underneath (ie. should SwiftUI expose UIKit/AppKit by default)? With traditional OOP imperative UI programming we’ve had many decades to refine and hone it. I understand Apples wish to move forward, but they definitely seem a bit too aggressive in adopting SwiftUI when we don’t even know for sure if it’s the correct way to do reactive UI. Unfortunately I think the only way we’ll figure out what the best approach is, is to try out things, and there’s no way that’s not going to be rough. Tho, I think Apple is doing it in such a way that it’s affecting it’s users too much. Honestly reminds me a bit of Microsoft.
Is swift better than objective C, not really, but is it easier for a developer to pick up who doesn’t have experience with either, Yes. Also, as an objective C purist and a neophyte, It kills me that they have started to hate on method swiziling. That was the coolest part of Objective C, IMHO. It harkens back to a time where Mac OS X really was this quirky developer’s paradise. As if nextstep had really been successful, and the die hard nerds had one over the messy c/c++ windows/unix dorks.
We should instead raise that barrier and keep raising it until quality improves.
There are legitimate improvements in the more reactive paradigm, as evidenced by React, Flutter, JetPack Compose and a bunch of others. The problem of course is that it’s still a very young technology, so we haven’t fully figured it out yet. Imperative OOP-based UI has been with us since the 80s, so there’s a decade of refinement behind that paradigm.
I’m pretty sure a more reactive UI framework is part of the answer, but if it’s specifically the way they created it with SwiftUI remains to be seen. I don’t think the answer is to just use old school imperative UI forever. That being said, Apple seems a bit too eager to move to SwiftUI before it’s proved its worth.
Exactly. Improve all you want… just make sure your QA department is very well-funded and give them veto power over anything that would change what a user doesn’t explicitly opt into.
I’ve got work to do and I already have enough wearing me down without it feeling like my tools were suddenly outsourced to a low-bid Chinese contractor.