Swift 3 had a purposeful effort to prioritize syntax-impacting changes and API changes as possible with the idea that Swift 4 and beyond would have backward compatibility for Swift 3 code.

Swift 4/5 will establish ABI compatibility, so that binary swift libraries will work across compiler versions

Finalized ABI has been deferred from Swift 4, if you haven't heard: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

Another year of breaking changes, hooray!

ABI != API, I think API-wise it should still be minimal breakage.

Yes I know that's what Swift 3 was trying to do, that's what I don't agree with. In my opinion the tradeoffs are just not worth it.

Whatever happened to graceful deprecation of older language features an APIs? They invalidated all the related example code online and created a ton of mandatory work for all iOS developers within a 1 year timeframe, that's nuts. In my opinion :)

Why are you using a work in progress and unstable language? You should have known from the start that, implicitly, that would require a lot of rewrites. Developing a language, especially as all-encompassing one such as Swift, is a very demanding task; what is the added benefit of having to support deprecated language constructs and APIs? Tools are lacking as it is.

This is the other thing that people say when we talk about Swift stability. "It's a work in progress." Apple certainly isn't giving this impression anymore.

1) Apple now has most code examples in Swift. 2) Most talks at WWDC are either in Swift only, or with ObjC as the alternative examples. 3) Swift was made available almost 3 years ago. 1.0 was released in Sept 2014. The Swift team was working on it for several years before that. This is now roughly 6 years that the team has been working on it. So when should we consider it stable? 10 years? Longer?

To release a new language, call it the future of iOS development, but also call it "unstable and beta" is a really poor way to treat your developers. I am then stuck between possibly starting a project with an entire deprecated development environment (ObjC), or one that's going to be changing every year forcing me to spend significant time upgrading and possibly introducing bugs.

It seems possible to have a language change and mature in a more sensible way than this, it's just harder and takes more work by the language maintainers. The easy way is just to break everything, which is what Swift is doing.

Agreed, but just anecdotally: I was job hunting over the last year, and I saw very few posts that said "We're sticking with ObjC for now because Swift is a huge technical risk" although I would have been happy to hear that.

There just seems to be a lot of momentum; everybody's excited about it, everybody wants to be on the bus.

That bus entails both good and bad, and everyone should be familiar with the risks of developing in a language in this state.

Personally, I wouldn't take any job application that only lists "Swift developer" seriously. Anyone serious enough about iOS development should know that you always need both. Also, not a big fan of telling people what technology to use forcefully.

They're trying to build the best language for the next 20 years and sometimes you can only see what works/doesn't work once you build it.

C++ taught us what happens when you let cruft creep in, so I can see it from. their point of view, however I can also see the developer frustration.

It should be much better with the Swift 4 transition.

I switched to Swift with version 1.0, it was terrible. Version 1.2 was when I was finally able to ship product. Since then it's just gotten better and better and the changes per version are a minor inconvenience. Usually am able to update a project in less than an hour.