Dynamic Swift

You don't necessarily want dynamism, you want metaprogramming.

Some of the classes in Apple's frameworks need to be overridden, some of them cannot be overridden, some of them don't both to call their overridden accessors - it's a mess! You can only discover this stuff by reading the documentation (if it's even there), when it ought to be enforced by a strict compiler.

Most of the of the community seems to have moved on, with the understanding that of course you can't reimplement performSelector/KVO/(insert dynamic, non-type safe feature that usually just bites you in the ass in the long run) from scratch, but we still have Objective-C that already implemented those features, and we will have it for years, if not decades, to come. Maybe Apple doesn't have to open source UIKit to prove their commitment to Swift (a short, albeit slightly unfair, summary of a blog post last week from another member of the old guard)

There seems to be a general lack of imagination, and lack of understanding that Apple would never rewrite UIKit or other large, existing frameworks in Swift. But, once Swift is more stable in a year or two, maybe you start thinking about new frameworks being written in Swift, with Objective-C compatibility, instead of vice versa.

Maybe you can't write Rails in Swift, but by god, why would you ever write Rails again? There's been two heavily up voted stories here in the past two weeks describing how awful it is to have a career dependent on a framework so dependent on dynamic untyped code. That matches exactly with my experience being pressed into service writing Rails code for a couple months - the development experience felt like the Stone Age compared to Swift, even if I could write a method ~20% faster.