Certainly a problem they&#x27;re aware of, and they&#x27;re trying to get as many breaking changes done in 3.0 as possible. There may or may not be more in 4.0, but they will definitely be smaller.<p>&gt; What does this mean looking forward?  Well, Swift 2 to Swift 3 is going to be an unavoidably disruptive change for code since Cocoa renamification is going to land, and we’re going to be building impressive migration technology again.  As such, we should try to get the “rearrange all the deckchairs” changes into Swift 3 if possible, to make Swift 3 to 4 as smooth as possible.  While our community has generally been very kind and understanding about Swift evolving under their feet, we cannot keep doing this for long.  While I don’t think we’ll want to guarantee 100% source compatibility from Swift 3 to Swift 4, I’m hopefully that it will be much simpler than the upgrade to Swift 2 was or Swift 3 will be.<p><a href="http:&#x2F;&#x2F;ericasadun.com&#x2F;2016&#x2F;02&#x2F;29&#x2F;getting-ready-for-swift-to-stop-breaking-code&#x2F;" rel="nofollow">http:&#x2F;&#x2F;ericasadun.com&#x2F;2016&#x2F;02&#x2F;29&#x2F;getting-ready-for-swift-to-...</a>