Whither Swift?
He&#x27;s missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft&#x27;s C++&#x2F;.NET situation.<p>If you look at the source code of the Swift standard library, &quot;toll free&quot; bridging code is everywhere. It even affects the language design of both Swift and Objective-C.<p>Yes there are still inefficiencies, but they are small. Apple has done everything humanly possible to make this interface efficient, seamless and sustainable.<p>So I think the plan is very clear: Don&#x27;t force people (including Apple itself) to rewrite old code. Make it possible and desirable to add new features to old Objective-C projects in Swift. Maybe let Objective-C die of old age at some point in the very distant future.<p>There is a ton of evidence that they are in this dual mode for the long haul.<p>I think the one flaw in their strategy is that people who like Swift will start to hate the antiquated object oriented design of Cocoa and some lower level OS services.<p>My prediction is that more and more of Cocoa will be wrapped with idiomatic Swift code that Objective-C devs will not want to adopt. At that point, there will effectively be two competing system APIs.<p>The pressure to make a clean break with Cocoa will grow because some un-idiomatic parts of Cocoa will be hard to wrap and people will call for a modern replacement for Cocoa long before Objective-C is gone.<p>So I think, most of the friction in this transition will arise on the library side, not with the languages themselves.