[mozumder]

I'm wondering if this means that the major work on Swift the language is complete? I've avoided it since it seems every year the language or the API changes... has it now settled? I really didn't want to go back rewriting code every year.

[manmal]

Swift 4 will be ABI stable, i.e. you will be able to use Swift 4 binaries with Swift 5. So, starting in September things will really settle down, or at least, upgrades are not a problem anymore. I guess that XCode will stay compatible with Swift 4+ for a long time in the future, and it might even mean that changes in Swift 5+ will only be additions, like blocks in Obj-C were.

UPDATE: Another comment here says that code compatibility is already fixed with Swift 3+.

[timjver]

Swift 3 code will be able to be used alongside Swift 4 code, in the future, but that's not to say that Swift 4 won't contain any breaking changes (it will).

[manmal]

Do you mean mixing 3 and 4 will work only if kept in separate source files?

[adamnemecek]

> I really didn't want to go back rewriting code every year.

The changes are mostly syntactic and like API changes. And Xcode has an integrated migration tool that's not too bad. I ported approx. 23KLOC of Swift (http://audiokit.io) from 2 to 3 in like 3 hours. And the changes are generally for the better.

[Grustaf]

Exactly my experience, I don't see why people complain about swift "always changing". I spent less than a working day in total on upgrading and I've been using only swift since it was launched. I don't like the new () requirement on method signature input types though...

[joelhaasnoot]

It can also be utter hell though if you rely on lots of external dependencies that don't share the same lifecycle.

[adamnemecek]

That is definitely true.

[emdowling]

By all accounts, we won't see another change on the same level as Swift 2.0 -> Swift 3.0 for some time. Having shipped production apps for all major releases of Swift, it definitely feels like the syntax and foundation of the language has settled in 3.0. Now it seems more focused on building on top of that.

[AlexeyBrin]

They've promised source code compatibility starting with Swift 3.0 and up. This means that in theory you should be able to recompile a Swift 3 code with the Swift 4 compiler.

[kibwen]

There's some nuance to the definition of source code compatibility:

> The Swift 4 compiler will include a language compatibility flag -swift-version that accepts 3 or 4 as arguments and controls the compatibility mode (SR- 2582 <https://bugs.swift.org/browse/SR-2582>).

> The -swift-version 3 compatibility mode has the goal of source compatibility as much as practically possible with Swift 3.x (including 3, 3.0.x, 3.x).

> The -swift-version 4 compatibility allows approved source code breakages from Swift 3.x (including 3, 3.0.x, 3.x).

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

TL;DR: there may be breaking source changes between Swift 3 and Swift 4, but the Swift 4 compiler will still be capable of compiling Swift 3 code. There's no indication whether the Swift 5 compiler will still be able to compile Swift 3 code, so you'll likely still have to migrate your codebase within a year or two.

[J0-nas]

At the IBM event he said that the current concurrency model (gcd) might be replaced/extended by an actor/task based model in version 5.

[asow92]

If you're truly worried, I would hold off just a little bit longer. Swift ABI stability is slated for Swift 4.

[stepanhruda]

ABI stability doesn't really matter for users, unless you're using 3rd party pre-compiled libraries. It's mainly an issue for Apple, shipping system libraries.

[mnem]

It's quite important if you're trying to provide libraries for developers to use...

[stepanhruda]

Closed source libraries.

[mozumder]

Is that expected this summer?

[mikeash]

Swift seems to be locked to Apple's yearly release schedule, so we should see prerelease versions of Swift 4 this summer, followed by a public 4.0 release around September.