Swift 3 is going to break your code. It’s a given. It was a given when the Swift team presented swift.org, opened the Swift evolution repo and mailing list, and allowed an early peek into already accepted proposals. If you’re not living in beta land, you will see it when 2.2 starts to warn what 3.x will break.
It’s a given when you see how Swift is reworking the way it interfaces with Foundation and adopting new guidelines for translating Objective-C APIs. It’s a given when there are still active and lively discussions about how the error system will evolve, how the standard library is going to change, and what default inheritance rules should be.
With this reality, you can choose one of the following approaches:
- Avoid Swift. C and Objective-C and their C++, web, and cross-platform friends can still help you build and sell product.
- Cautiously test the Swift waters but delay full adoption.
- Embrace Swift and fight to maintain the language’s immediate integrity for production code.
- Embrace Swift and try to get as much pottery broken and re-geared in the 3 update to ensure that the 4 update and later involve relatively minor changes, adding features instead of breaking them.
I vote for option 4.
All changes are costly but large early changes are ultimately less expensive than slow yearly language updates. That’s not to say that changes aren’t traumatic or expensive, regardless of when they happen. They are.
Imagining that all the important changes can be adopted at once is a fantasy. But the sooner the language approaches stability, the more both the developer community and your customers will benefit. You can complain from the sidelines or get involved in setting the direction.
You can’t properly develop in Swift without preparing for refactors. The two core realities of adopting Swift right now are writing tests and documenting the hell out of everything. Allocating time and building tests and comments are part and parcel of getting ready for the next big flood.
The flood is gonna happen. Will you be there?
 If the tests work, great. If not, your comments address the “what was I thinking when I wrote this” bit that moves beyond “self documenting code” and “obvious method names”