The Cost of Swift to Apple Platforms

I do not write as much code for Apple platforms today, but I am still enthusiastic about the technology. Swift has become intertwined with Apple platforms, and it has had a headline role for the last decade at WWDC. Looking back, I have mixed feelings about how influential Swift has been to Apple's developer story. If the goals of Swift were to replace Objective-C, be memory safe, and performant, then the language has achieved many of those goals. However, if the goals were to advance Apple platforms and enable better apps, then I'm not sure it has moved Apple or the community into a better position.

A recent Hacker News comment listed several points which I agree with.

First, Swift is closer to a replacement for C++ rather than Objective-C. The original Swift team was not as knowledgeable about Objective-C as they should have been. For instance, in a talk about The design of Swift Dave Abrahams (who designed significant parts of the standard library) gave examples of Objective-C that most experienced developers would never write. He's contributed greatly to C++ and Swift and been a positive influence, but I doubt he had too much practical experience with Objective-C.

Still, it would be fine if the practical application of Swift was as good as Objective-C. Both languages are used to write apps like 99% of the time. A significant portion of app specific code is building UIs. Five years after SwiftUI was introduced, I do not think think it is better than UIKit. The opaque declarative nature mixed with the Swift tooling has made SwiftUI a "great when it works, but maddeningly frustrating when it doesn't" experience.

Memory safety and less undefined behavior are absolutely great goals for a programming language, but if Apple wanted to advance app development, they should have concentrated on frameworks. I agree with the Hacker News comment that Apple framework development dramatically stalled as Swift took over mind share. Core Animation-like advances disappeared while everyone was figuring out how to rewrite code into Swift. Nearly a decade later, Apple developers are finally getting concurrency friendly developer experiences and significant updates to frameworks such as CoreData.

A follow-up comment also was insightful in how the design versus practical usage of Swift is in opposition to the original goals of Swift. Enforcing correctness is great, but it would be better if the underlying foundation was correct first. If the vast majority of the underlying framework calls are to Objective-C or C code, then any gains in correctness or performance are meager considering app code is usually insignificant compared to all the framework code used.

Personally, Swift is a better language than Objective-C, even though I never really thought Objective-C was bad. I like my algebraic enum types, and I've been convinced generics are great. In the end, Swift is a tool like a fancy hammer or safety saw. For any maker, it is nice to work with great tools, but if you're still forced to build with the old architectural designs and limitations, then focusing on the tools is missing the forest for the trees.