This is why: it's hard to get things right. When I started programming for Apple almost 20 years ago (mainly using Objective C), too many hours of my time were spent making sure that I was dealing with memory correctly. Easier in Objective C than C's primitive malloc/free, but still hard, even with the tools to help. During my time there, new things were tried: firstly garbage collection, and then automatic reference counting. This last got rolled into Swift, and hours spent looking for memory leaks or dangling pointers become a thing of the past. It is still possible to have memory problems in Swift, but mostly they can be avoided.

In the case of UI, use of a library is essential. And of course boring technology has libraries. But the real problem is layout: not just where your elements sit on the page, but where they go after the user resizes a window. In the early years, this was not too difficult because screens were mostly fixed size and in landscape mode. But now there are many aspect ratios, four possible orientations and so on. Apples earlier solution was a system called Layout Constraints. Frankly I found them really difficult to use, even when I stuck with the ones provided within Xcode. SwiftUI seems to me the exactly correct way to deal with layout complexity. Admittedly lots of it needs to be improved (as the article points out), but I would much rather use a declarative approach to layout than any alternatives I know of.