Objective-Swift
Now, these aren’t really problems with Swift — they’re problems with pure Swift. […] Given that, I made the pragmatic decision to start using @objc protocols, classes, and collection types where those things make sense, where Swift fought against my design.
And suddenly the language is a joy to use. It’s like Objective-C but with type inference, no .h files, fewer imports, shorter syntax — and I get the things I was missing.
This is my current approach as well. Swift has a lot to offer just as a better Objective-C. I’m not enamored with generics, and protocols seem like a good idea that in practice is currently too much of a pain to use. Likewise, the standard library is still in flux and not fully understood, whereas Foundation is stable and a known quantity. Foundation is great. Why not keep using it?
It’s also my hunch that by staying closer to the Objective-C world you are more likely to avoid bugs and confusing error messages from the Swift compiler. And you can somewhat avoid painting yourself into a corner because any code should be relatively easy to port back to Objective-C, if necessary. It’s not possible to subclass a Swift class from Objective-C, though—even if it inherits from NSObject—so hopefully you won’t run into any problems with a leaf class.
Update (2015-08-14): Joe Groff:
ObjC and the ObjC runtime also aren’t going away. Using @objc for things still we suck at natively is good and encouraged.
My intuition says they’ll naturally wither like Carbon did. And we won’t mind.
But it’s nice to hear there aren’t plans to artificially axe ObjC.
