The final version of Swift 3.0 will be released alongside iOS 10 and macOS Sierra in the fall, but the fact that Apple develops Swift out in the open now means that we know more about its progress than we do about Apple's operating systems. Chris Lattner, a senior director of the Developer Tools Department at Apple, today posted a lengthy note to the Swift mailing list that looks back at the development of Swift 3.0 and sets some expectations for Swift 4.0 next year.

The note is worth reading in its entirety for those interested in programming in Swift and in contributing to the language itself—the Swift 3.0 retrospective focuses mostly on the benefits and drawbacks to going open source. Lattner describes the "vibrant community" as "fantastic," though he does note that open-source development "is slower and less predictable than 'closed design.'" Lattner says "the end result is significantly better, and therefore the tradeoff is worth it," even if "it is impossible to make everyone happy." The latter sentiment should ring true to anyone who has ever worked on any open source project.

Apple plans to release two major Swift updates between now and fall of 2017—Swift 3.1 in the spring and Swift 4.0 in the fall, along with whatever other minor bugfix releases are necessary. For Swift 4.0, Apple would like to focus on source and ABI stability first, and move on to other features once work on those two things is complete. After that, Lattner outlines a number of goals that the team would like to accomplish if time permits:

Reflection: The core team is committed to adding powerful dynamic features to Swift. For example, Swift 3 already added nearly all the infrastructure for data reflection (which is already used by the Xcode memory debugger). We should use this infrastructure to build out a powerful user-facing API. Similarly, we would like to design and build out the implementation for dynamic method reflection runtime + API support.

First class concurrency: Actors, async/await, atomicity, memory model, and related topics. This area is highly desired by everyone, as it will open the door for all sorts of new things on the client, server and more. We plan to start formal *discussions* about this in Phase 2, but it is unfortunately crystal clear that a new concurrency model won’t be done in time for the Swift 4 release. This is simply because it will take more than a 12 months to design and build, and we want to make sure to take time to do it right. It also makes sense for the memory ownership model to be better understood before taking this on.

Generics improvements: The generics manifesto includes many exciting enhancements to the generics system, many of which will not be specifically required for ABI stability of the standard library, but would make Swift generics more powerful and expressive.

.swiftmodule stability: At some point we need to stabilize the “.swiftmodule” binary file format (or replace it with a different mechanism) to allow 3rd party binary frameworks. This is a very large amount of work over and above what is required for ABI stability of the standard library.

New scripting features: Regular expressions, multi-line string literals, etc. Having these would make Swift much more appealing to the crowd doing scripting and those building web technologies, among others. They’d also help round out the String model.

Property behaviors: This feature promises to provide powerful abstractions over the existing property model. The deferred SE-0030 proposal describes this opportunity well.

So many others: Submodules, implicit promotions between numeric types, importing C++ APIs, hygenic macro system, guaranteed tail calls, making enums enumerable, typed ‘throws’, user defined attributes, abstract methods/classes, better SIMD support, ‘dynamic’ for non- at objc, data parallelism support, higher kinded types, …

Syntactic sugar: I won’t list them all, but there are a ton of other trivial to small proposals that frequently come up, typically things seen in other languages that solve specific problems. These are the lowest priority to tackle for Swift 4.

Aside from those specific items, the note gives the casual observer some insight into how Apple's open-source Swift efforts are going. Apple is still very much in the driver's seat, dictating goals and rough timelines to the rest of the community and taking an active role in soliciting and submitting proposals, but the language still relies on the work of the wider community when coming up with specific implementations.