The Swift Programming Language book states that Swift is "designed to scale from 'hello, world' to an entire operating system." This has troubled me from the start, and I brought it up again recently on Twitter:

http://twitter.com/amolloy/status/735105280388804609

My basic issue with the idea is that it involves a very simplistic view of the problem space programmers work in. It assumes that the tools required by a programmer developing, say, a compiler are the same as those required by a programmer working on an app. But, as someone who has worked on both compilers and apps (and games, and servers, and so on), I feel pretty strongly that this is simply not true.

I have a great deal of trouble imagining a language which does a great job of providing all of these tools1. The phrase "Jack of all trades, master of none" comes to mind. Granted, there are some very smart people2 working on this problem. They may well see something I don't, but so far it doesn't look like it.
So, I would like to propose an alternative future for developing on Apple's platforms. A future that felt a little far fetched when Swift was first announced, but somehow feels more likely as time goes on. In this vision of the future, Apple supports both Swift and Objective-C, not just during a few transition years but indefinitely.
In this fantastic future, Swift would be the new C and C++ instead of the new Objective-C. Swift would be behind the critical code where type safety and performance are paramount, while Objective-C would continue to be the language of choice for things like user interfaces. Rather than trying to have One True Language that does a mediocre job of all of these things, we would continue to have two languages, each great at solving the problems that play to their strengths.
This would basically be a reification of the situation we have today. Instead of leaving the future of Objective-C in limbo, Apple would clarify that this is the plan. New APIs that are performance or security critical (think Metal, or a replacement for the Security framework) would be Swift-first3, as would low-level operating system code. New APIs that can best be expressed with Objective-C's dynamism would be Objective-C first.
Apple has already done an admirable job of making Swift and Objective-C interoperate. In this future they would take this even further. Mixing Objective-C with Swift would be as painless as physically possible. This would not only allow but encourage developers to choose the best tool for the job, even within the same project.
This would require some changes from outside of Apple, too. We would stop arguing over whether this project should be implemented in Swift or Objective-C, but instead argue whether this feature or even this class should be implemented in Swift or Objective-C. Mixed language projects would become the norm, rather than the result of an in-progress transition.
In this future, the two languages would continue to grow together, too. Like a lot of the things in this post, that has already happened to some extent4. I confess I would love to see an Actually-Objective-C-Without-the-C.
To me, this future feels the most sensible. It allows us to have our cake and eat it, too. For my part, I've started doing feature-level evaluations of which language to use in my own projects, with great success. Picking the correct tool for the job makes all the difference in the world. I'm hoping for a future where this is embraced by Apple and the Apple development community.