Tech —

Craig Federighi talks open source Swift and what’s coming in version 3.0

Swift is available under an Apache license, and source compatibility is coming soon.

Apple's Craig Federighi introducing Swift at WWDC 2014.
Enlarge / Apple's Craig Federighi introducing Swift at WWDC 2014.
Apple

When Apple unveiled Swift 2.0 at WWDC back in June, one of the bigger announcements was that the language would be going open source by the end of the year. The time has come—­just a few weeks before its self-imposed deadline, Apple has launched Swift.org and is releasing a big chunk of code (as well as some guidance for Swift 3.0) to the public.

Ars had a chance to chat with Apple Software Engineering SVP Craig Federighi about Swift’s openness, the future evolution of the language, and when developers can expect it to mature and settle down.

The basics

Swift is being released under an Apache 2.0 license, which is incidentally the same license Microsoft used when it open-sourced a big chunk of its .NET framework last year. The project will be hosted on GitHub and will include the compiler, the LLDB debugger, the REPL command-line environment, the standard and core libraries, and code from supporting projects. New to Swift (and also open source) is the Swift Package Manager, described as an “early-stage project” that will serve as a repository for Swift modules and will evolve with input from the community.

Most of that is covered under the standard Apache license, but Federighi tells us that Apple has also included a more permissive runtime exception, “so that if you build code in Swift and parts of the Swift library are generated in your own code, you don’t have to provide attribution in that case.”

Apple engineers working on Swift will start using the GitHub repos, developing the language out in the open.

“The Swift team will be developing completely in the open on GitHub,” Federighi told Ars. “As they’re working day-to-day and making modifications to the language, including their work on Swift 3.0, all of that is going to be happening out in the open on GitHub.”

So instead of getting a big Swift 3.0 info dump at WWDC 2016 in the summer and then digging into the Xcode betas and adapting, developers can already find an “evolution document” on the Swift site that maps out where the language is headed in its next major version.

While the code itself will live on GitHub, the community surrounding Swift will find its home on Swift.org. Here, developers will be able to access a bug-reporting and -tracking system, mailing lists, a Swift engineering blog (something Apple already offers), community guidelines, Swift tutorials and documentation, and developer and API design guidelines. In other words, these are the kinds of things you see on the pages for any open source programming language.

Platforms: Official OS X and Linux support, community support for the rest

Officially supported ports of Swift currently include those for Apple’s platforms and also Linux, which is what the company promised back in June when it made the original announcement. That covers a lot of ground for Swift developers (who will generally already be running OS X) and developers in general (who probably use Linux more widely than the general populace). Apple’s Linux tools include support for the nascent package manager, the LLDB debugger, and the REPL command-line environment.

As for other platforms, including Windows, at least initially Apple is going to lean on the community to provide that support if there’s demand for it.

“[Windows support] wasn’t something that in terms of us catalyzing this initial release that we wanted to take on directly,” Federighi told us. “We think Linux and of course our platforms provide a great foundation to get started. But we’re very open to ports to other platforms being contributed to the core project, and certainly given that LLVM, Clang, and LLDB, which are foundational technologies to Swift, are already available, already ported to Windows. I think it’s foreseeable that someone in the community, whether led by Microsoft or others, would be doing that port.”

Why open up Swift?

In open-sourcing Swift, Apple has two main goals in mind. The first and most obvious is to make Swift code more portable and versatile, enabling its use in projects outside of apps for Apple’s platforms.

The company’s long-term vision is even more ambitious. “We think [Swift] is how really everyone should be programming for the next 20 years,” Federighi told Ars. “We think it’s the next major programming language.

“A number of developers, including enterprise developers like IBM, very early on as they began developing their mobile applications in Swift, really wanted to be able to take the talents that their developers were developing and even some of the code and be able to deploy it in the cloud, for instance,” Federighi continued. “We thought the best way [to enable that], ultimately, was open source.”

The other goal is educational: when developers put time into learning Swift (or when educators take the time to teach it), Apple wants those skills to be more broadly applicable.

“We’re working with educators, and many professors are very interested in teaching Swift because it’s such an expressive language that’s such a great way to introduce all sorts of programming concepts,” Federighi said. “And enabling it as open source makes it possible for them to incorporate Swift really as part of the core curriculum.”

When we spoke with developers about the first year of Swift back in June, Swift’s teachability was definitely a major selling point. As useful as Swift might be to communicate programming ideas, it’s ultimately more useful to be able to take that knowledge and use it in multiple places.

"When you’re first learning, it’s usually about whether your code compiles or not, and I like that Swift won’t even let you compile in some cases without starting to think of some of those things," said Lesley Baker, an iOS developer and a teacher with App Camp for Girls. "Hopefully that will lead to a better understanding of what’s going on and not be too frustrating.”

That said, according to Swift.org, developers submitting apps written in Swift to one of Apple's app stores still need to be using Xcode on a Mac.

How will this change the language? And when will Swift stabilize?

Making Swift open source and developing new versions out in the open makes it easier for developers to see what Apple is doing, but it also makes it easier for them to contribute to the project directly. Apple says that developer feedback has already been instrumental in developing features and taking the language from beta to 1.0 to 2.0, but at least theoretically, the company will no longer be the sole arbiter of what does and doesn’t end up in the language. Developers can submit pull requests, and Swift.org outlines the processes that should be used when developers want to propose changes.

“When you look at many of the language features that we announced in Swift 2.0 that are now out in terms of error handling and the guard statements, availability, controls, and so forth, these were all based on that dialogue that’s been ongoing with developers who’ve been adopting Swift in their real applications," Federighi said. "With Swift being developed out in the open in open source, we think it’s going to deepen that interaction considerably."

Swift is still a young language, and as well-received as it has been, that still creates frustration for developers trying to develop and maintain code. Swift 1.x code created six or 12 months ago might not even compile today in current versions of Xcode, a problem Apple is definitely aware of.

“We’ve been very open in saying we would provide source evolution tools for our developers,” Federighi told Ars, “so if they write their Swift code and then as we evolve the language we’ll provide the tools to help them move their source code forward.”

But the company also has plans to fix the broader problem, a fix that is only going to become more important now that more developers can contribute more directly to the language. One of Apple’s goals for Swift 3.0 is source compatibility going forward so that Swift code that is written may need to be recompiled as the language continues to evolve, but it will need to be rewritten or changed less frequently or not at all.

And where does this leave Objective-C?

As for Objective-C, Swift’s newfound openness doesn’t change anything about its position in Apple’s ecosystem. It has been around for years, it’s still being used to code many apps running on Apple’s platforms (including Apple’s own), and Apple is still adding to it as it deems necessary. But Swift is clearly where most of the future investment is going, and Apple would prefer that developers starting new projects start them in Swift if possible.

“Objective-C is not going away. We still love Objective-C as a language; we still very much depend on Objective-C and do a tremendous amount of work in Objective-C here internally at Apple,” Federighi told Ars. “We’ll be supporting Objective-C and continuing to evolve it as necessary to fit into this evolving world. We do think that Swift is the language that we recommend for new developers to our platform who are investing for the future and building new apps. We think Swift is absolutely the right place to start. But we’ll continue to maintain, advance, and support Objective-C for as far as we can see.”

That statement generally tracks with how developers have told us they’re using Swift and Objective-C. Some are sticking with it because of familiarity or because they don’t want to mix their Swift code with Objective-C code, but more often we’ve been told that new projects and new chunks of old projects are being written in Swift instead.

Apple seems committed to continuing support for Objective-C for the foreseeable future, but if (when?) the company decides to pull the plug, no one wants to be caught unawares. Swift’s increasing maturity, the promised source compatibility for Swift 3.0, and the open source version’s wider applicability in the real world should all make developers more comfortable with making that transition.

Channel Ars Technica