Apple hasn't even delivered its Swift 3 language yet and already is getting an early thumbs-up from developers for planned Swift 4 follow-ups, which will focus on application binary interface (ABI) stability, concurrency, and scripting.

Stage 1 development in Swift 4 will prioritize source stability as well as resilience, enabling public APIs to evolve over time even with ABI stability. "For example, we don't want the C++ 'fragile base class' problem to ever exist in Swift," Lattner said.

Swift advocates were pleased with the ABI plans. "Stabilizing the ABI was originally a goal for Swift 3, but it got kicked down the road," said Aaron Hillegass, CEO of Big Nerd Ranch, which builds applications for Apple's iOS platform. "Stabilizing the ABI is very important because at this time, every Swift app includes the entire standard library, which adds at least 10MB to every app."

At PerfectlySoft, which is leveraging Swift in its Perfect application server, CTO Kyle Jessup said ABI stability was important for system-level software and distribution of precompiled libraries. "Apple is serious about pushing Swift as its main programming language, and with a well-defined and stable ABI, it can begin to consider introducing Swift-only APIs into their SDKs."

Other capabilities planned for this stage include generics improvements for the standard library and string re-evaluation. "String is one of the most important fundamental types in the language," said Lattner. "The standard library leads have numerous ideas of how to improve the programming model for it without jeopardizing the goals of providing a Unicode-correct-by-default model. Our goal is to be better at string processing than Perl."

Jessup believes that string processing is imperative for writing almost any piece of software today. "Swift's Unicode-correct by default for string objects were a great move, but some of the APIs could be made more consistent and useful or powerful," he said. "Hopefully, after revisiting Swift strings, it will become easier to write parsers and other important tools using Swift."

Lattner would like to see a memory ownership model added as well. "Adding an opt-in Cyclone/Rust-inspired memory ownership model to Swift is highly desired by systems programmers and folks who want predictable and deterministic performance," such as in real-time audio processing code, he said.

But Hillegass was skeptical about how much success Apple would have in emulating Rust's memory model. "Everyone in the developer community is impressed with Rust's memory ownership model -- it's an impressive blend of safety and performance especially in multithreaded environments," he said. "However, I think it's going to be very difficult to bolt this on afterward. The design of Rust and its libraries were all based on that memory ownership model."

Apple is planning to add "first class" concurrency, including actors, async/await, atomicity, and memory model, in stage 2 of Swift 4's development, though Lattner concedes it will take more than a year to design and build these capabilities.

"Concurrency is the problem everyone is trying to solve today," Hillegass said. "Everyone has multiple cores on the their device, and nearly every app accesses the cloud. Languages like Go and Elixir have very compelling approaches to concurrency built into the language. If Swift is going to be an alternative, especially on the server, it needs to have good answers to the questions around concurrency. We are especially interested to see how the memory management model of Swift changes to better support a multithreaded environment."