If Swift succeeds, Objective-C will go away. It won't be deprecated, but it'll move to Florida to enjoy its golden years. It'll spend days running the legacy app with a million lines of code, and its nights sipping margaritas with the OAuth library everyone fears rewriting. Many years from now, you'll open the obituary section of the iOS Release Notes to see Objective-C passed on. So it goes.

While the iOS toolchain always supported multiple languages, each solved a different problem. C++ exists for cross platform apps, especially games. Use C if you need raw performance or bit fiddling.

Apple didn't say, "Objective-C and Swift are good for different problems." At the 2014 wwdc keynote, it was first described as "modern." This year Swift is "faster to write and easier to maintain." Apple says it loves both languages but throws Swift the best bar mitzvah.

A two language ecosystem fragments the iOS developer community. Your company can approve a single language and annoy 50% of developers, or support both languages and waste twice as many hours bikeshedding about style guides.

Apple wouldn't invest in Swift unless their long term goal was to replace Objective-C. They aren't ready to say it, because they know they could be wrong. They don't want to repeat the embarrassment of the garbage collector introduced in Mac OS X 10.5, deprecated in 10.8, and removed in 10.10. It was better for the ecosystem, but tell that to the poor schlub who ported to the GC and back.

We're in the first stage of developer advocacy. First Apple says, "You should check out Auto Layout!" They collect a year's worth of feedback, fix the bugs and annoyances, and say, "You should really be using Auto Layout." Then they release iPhones with different sizes. "You should really use Auto Layout. And check out size classes!" Oh look, iPad multitasking built on size classes.

Swift is a success among early adopters, but larger companies are "Wait and See." When Apple pulls the trigger and says Swift is the chosen language, it has to be a one hit kill. It takes one rocky transition for your CTO to eye Xamarin. "What? Two languages for iOS? Let's write it in .Net and unify the whole company!"

Swift has learned a lot from the Python 3 debacle. Six years after release, 68% of developers write most projects in Python 2.x. One problem was backwards compatibility, with third party libraries breaking unless they were ported.

Swift has to have perfect backwards compatibility, and they've done a spectacular job. It's absolutely magical until it isn't. I wasted an hour trying to interoperate with C function pointers before giving up and dropping down to Objective-C. Every Swift 1.2 project I've worked on has required these Objective-C shims.

Today, you can't be a Swift developer without first being an Objective-C developer. Before Apple can say, "Use Swift," you need to be able to only use Swift. They're making strides; a few weeks after my function pointer struggles, the Swift 2.0 release addressed my very problem.

Another Python 3 problem was that you can't convince a community to drop everything and rewrite code that works perfectly well unless there are significant rewards. Python 3's language purity wasn't enough. "Yeah, that's cool, but I'll be over here shipping."

The Swift team takes the high road. Joe Groff said, "If it really is better, then we won't need to coerce people to get them to use it."

The fastest way to do this is to iterate in the open, running in real world apps. But Swift needs the freedom to make sweeping languages changes without years of deprecation notice. They need people using it, but not too many people, and they need to know what they're getting into. So we're now in this middle ground, where "Objective-C isn't going anywhere, but you should really try Swift!"

Swift will approach a tipping point. When Objective-C migration is perfect and developers beg managers for permission, Apple will say, "You should really be using Swift", and discourage Objective-C. Years later, it may be deprecated, but it never will be removed. It powers iOS, and years after deprecation OS X still runs bits of Carbon.

When I tweeted Objective-C will go away, I kicked off the Internet's favorite pastime, "Telling you you're wrong." I picked my words carefully. When Objective-C goes away, it will not be through deprecation, but irrelevance.

If you stick to Objective-C, there are three ways things could play out:

  • Swift fails and goes away: Good job! You were a mature engineer and saved your company time, money, and risk.

  • We're stuck in a two-language world: You may miss out on some great opportunities.

  • Swift succeeds: Objective-C is the new Cobol. If you enjoy legacy apps, you've got job security until the heat death of the universe.

What's the best case scenario for diving into Swift?

In 2005, I discovered Ruby on Rails. It was bleeding edge and not safe for production, but I found opportunities to build larger and larger projects in it. By 2007, I saw massive returns in my career. In 2009, my Rails background landed me my job at Twitter.

Learning bleeding edge technology is like investing in a startup: you take on insane risk for potentially massive rewards. That's why you only make an angel investment if you're comfortable losing the money. Keep your retirement in mutual funds.

There are totally valid reasons to hold back on Swift. Anecdotally, Swift updates take a day or two to migrate. Maybe your codebase is a lot larger, or you can't take that disruption. Totally understandable, today.

If you're managing a large company, last year should have been "Wait and See." 2015 is the year you should ramp up and plan around its future. This is the right time to try it on non-critical, green field projects.

You don't need to bet everything on Swift, but you better dig in.