There has been some discussion lately about Swift not having the dynamic features of the Objective-C runtime. Brent Simmons has been doing a great job of pointing out why this is a problem.
It’s very easy to overlook the importance of the dynamic runtime environment. Many of the things it enables happen behind the scenes. There’s no better example of this misunderstanding than a developer who says their app is “Pure Swift”.
That’s because you can’t currently write an app that only uses Swift. The purity of your code is lost as soon as you #import UIKit.
A picture’s worth a thousand words, so here’s a project that demonstrates why it’s impossible. The app itself is ridiculously simple: there’s a button, a few labels, and a single action method. It’s as “Pure Swift” as you can get.
This project also contains an Objective-C category named NSObject+Adulterated. This category overrides two methods that lie at the heart of the dynamic runtime: -respondsToSelector: and -methodForSelector:. The normal operation of these methods is not affected; the only additional functionality is some logging to the console when they’re used. Other than being in the bridging header, the code is not used directly by the app.
When you run the app, you’ll immediately see all the places where Swift is not being used. Pretty much everything you take for granted in your app is using the dynamic runtime. Layout, drawing, animation, and event handling are all dependent on something that Swift doesn’t have yet.
Of course, you’ll immediately say, “This isn’t Swift’s problem! Just rewrite the frameworks!”
And that is exactly the point I’m trying to make.
The community around Swift’s evolution is amazing. The language is improving quickly and dramatically thanks to talented developers inside and outside of Apple. It’s a remarkable open source project.
My concern is that there isn’t a corresponding discussion about the things we’re going to build with this new language. As you’ve just seen, frameworks are important, yet there is no uikit-evolution mailing list. There is an imbalance between the tool and the craft.
I’m guessing that part of this problem lies within Apple itself. There are plenty of developers in Cupertino who have built large applications and the frameworks that they use. I’m absolutely certain that this subject has been discussed in detail by some very smart folks. And they, of course, can’t talk about internal projects.
My suggestion for the folks on the Swift project is to be a little more forthcoming about future plans with frameworks and other infrastructure besides the language itself. It’s a big piece of a puzzle that long-time app developers want and need.
A lot of hand-wringing could be ameliorated with a simple “Yep, we’re working on it.”