People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions)
I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff.
> They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff.
At WWDC 2022 they specifically said that Swift+SwiftUI is the best way to build apps, and the future of their platforms. I thought AppKit/UIKit would stick around, but I guess not.
---------------------------
Edit: Here's the direct quote from the "Platforms State of the Union":
> We're continuing to expand our adoption of SwiftUI across our apps and system interfaces. For example, iOS's new Lock Screen widgets were designed from the ground up using SwiftUI. The new Font Book app was completely rewritten with it. And the modern, forward-looking design of the new macOS System Settings app was built using it. Swift and SwiftUI were designed from the start to provide a single, native language and API for all Apple platforms. You can learn them once and apply them everywhere. Whether your vision is to provide quick access to information at a glance on Apple Watch, productivity tools on MacBook Pro and iPad, new experiences on iPhone, or a new way to relax with Apple TV, Swift, SwiftUI, and Xcode provide a next-generation integrated development platform to help you build apps for all of our products. Now, if you have an existing app, it's easy to adopt these new technologies incrementally. And if you're new to our platforms or if you're starting a brand-new app, the best way to build an app is with Swift and SwiftUI.
The slide had a Swift, SwiftUI, and Xcode logo with nothing else.
I'll start getting concerned when they rewrite any of their serious apps in Swift(UI). (i.e. Logic, FCP, Xcode, Finder, Instruments, iMessage, Mail, Calendar, etc.)
> The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary. For a while now, you've seen us hard at work defining the next generation of integrated language, frameworks, and tools: Swift, SwiftUI, and Xcode Previews.
>
> Tight integration in a development platform like this requires that all three pieces be designed and evolved together, both driving and driven by one another. Swift result builders were inspired by SwiftUI's compositional structure. SwiftUI's declarative views were enabled by Swift value types. And Xcode Previews was specifically designed for, and enabled by, both. Now, the result is the best development platform that we have ever built. And this year, Swift, SwiftUI, and Xcode all have fantastic updates that take this vision further, and make it even easier for you to build great apps for all of our platforms. And it all starts with Swift. Now Ben from the Swift team is gonna tell you all about what's next.
The ironic thing is that functional reactive idiom is not about pure functions. It's about dealing with the impurity only once, at state management.
But if you don't keep track of the impurity dependencies on your language, you will need to rediscover those dependencies during compilation, and besides surprising the developer all the time, that's a really nasty problem to solve. That's why it's always solved badly.
MFC? As somebody who has worked with MFC in some way or another for the past 25 years, there are worse examples out there. The beauty of MFC was that it was pretty simple layer on top of Win32 and the source code was provided. You can continue to use it with some of their newest stuff using XAML Islands.
Ironically it is still the best way to do C++ GUI development on the Microsoft stack, after they killed C++/CX, and replaced it with the pre-historic tooling C++/WinRT.
However for a real nice C++ GUI development experience on Windows, going with C++ Builder or Qt would probably be a saner option, as the WinUI team doesn't seem to get it, and MFC only gets minor updates nowadays.
On the Microsoft side, it is still the best way to do C++ GUI development, after they killed C++/CX, and replaced it with the pre-historic C++/WinRT tooling (return to the ATL days but without VS tooling support).
I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff.