Swift.org

The Swift.org Blog

2015-12-03T02:01:01-08:00

Welcome to the blog on Swift.org! Today we launched the open source Swift project along with the Swift.org website. We couldn’t be more excited to work together in an open community to find and fix issues, add enhancements, and bring Swift to new platforms.

This blog is where the engineers working on Swift will make announcements and highlight important community topics.

Projects

Swift is made up of a number of different projects, providing a complete ecosystem for building great software. The Swift compiler project interprets Swift syntax, produces diagnostics to help you write correct code, and employs LLVM to generate machine instructions. The LLDB project is a first-class debugger that includes a REPL for interactive programming. And the Swift standard library project includes all the core types and basic functionality you need to write software in Swift.

Today, we released two additional projects for Swift in open source: the Core Libraries project, and a new Swift Package Manager project.

Swift Package Manager

The Swift Package Manager is a brand new project that strives to create a powerful, user-friendly tool to build and share Swift code. We are focused on ensuring the package manager is great at sharing source code, rather than compiled binary libraries. This project is very early in development, and will be designed and developed using Swift’s open, collaborative process.

You can find example package repositories at the Apple home on GitHub, as well as the source code and additional information for the package manager itself.

Core Libraries

The Swift Core Libraries project is a higher-level set of APIs, above the Swift standard library. These libraries offer functionality such as localization, networking primitives, unit testing, user preferences, and more. These libraries also introduce coding conventions that will be useful as you write more Swift code, and create new packages.

The core libraries are based on frameworks included in Apple platforms, namely Foundation, libdispatch, and XCTest. The Swift open source versions of these frameworks are intended to make it easy to use the same Swift code with consistent functionality across multiple platforms.

Swift.org Website

This website is the home of the Swift project with links to the resources you will need to participate in the community. We invite you to click around the navigation area to explore the site, but we wanted to call out a few key links here in our inaugural post:

The Apple home on GitHub hosts all the Swift source code
The Swift mailing lists are how we interact
The Getting Started pages will help you setup a Swift development environment
The Download page includes pre-built binaries for the supported platforms
The Swift Evolution Process describes how new features are proposed

Welcome to the open source Swift community.

– The Swift Team

The Swift Linux Port

2015-12-03T03:01:01-08:00

With the launch of the open source Swift project, we are also releasing a port that works with the Linux operating system! You can build it from the Swift sources or download pre-built binaries for Ubuntu. The port is still a work in progress but we’re happy to say that it is usable today for experimentation. Currently x86_64 is the only supported architecture on Linux.

Here are a few highlights of what’s working in the port today:

Swift without the Objective-C Runtime: Swift on Linux does not depend on the Objective-C runtime nor includes it. While Swift was designed to interoperate closely with Objective-C when it is present, it was also designed to work in environments where the Objective-C runtime does not exist.
The core Swift Language and Standard Library on Linux shares most of the same implementation and APIs as on Apple platforms. There are some slight differences of behavior because of the absence of the Objective-C runtime on Linux (noted below).
The Glibc Module: Most of the Linux C standard library is available through this module similar to the Darwin module on Apple platforms. Some headers aren’t yet imported into the module, such as tgmath.h.

To try it out, just import Glibc.
Swift Core Libraries: The Core Libraries provide implementations of core APIs from Foundation and XCTest to be used on Linux without Objective-C . The intention is that these APIs are available in a cross-platform manner regardless of whether you are using Swift on Apple’s platforms or Swift on Linux.
LLDB Swift debugging and the REPL: You can debug your Swift binaries and experiment in the REPL just like you do on macOS.
The Swift Package Manager is a first class citizen as it is on Apple’s platforms.

Here are some things that aren’t quite working yet or are planned for the future:

libdispatch: Part of the Core Libraries, updated Linux support is in progress. You can follow development on the libdispatch project on GitHub.
Some C APIs: Although this is generally true for all of our supported platforms, a few constructs in C aren’t imported yet into Swift. This will cause some APIs to be unavailable, such as those that contain varargs / va_list. However, in recent months Swift’s interoperability with C has significantly advanced, gaining support for named and anonymous unions, anonymous structs, and bitfields.
Some String APIs: The Standard Library’s String is missing implementations of several important APIs because they are currently tied to the implementation of NSString on Apple’s platforms.
Runtime Introspection: When a Swift class on Apple’s platforms is marked @objc or subclasses NSObject you can use the Objective-C runtime to enumerate available methods on an object or call methods using selectors. Such capabilities are absent because they depend on the Objective-C runtime.
Array<T> as? Array<S>: Some mechanisms, such as casting containers with different associated types, currently do not work as they relied on bridging mechanisms with Objective-C.

We’re really excited to be able to release the open source project with a great head start for Linux support that you can try right now! There is still plenty of work to be done, so we hope to see you contribute to Swift to make the Linux port even more complete.

Swift 3 API Design Guidelines

2015-12-03T04:01:01-08:00

The design of commonly-used libraries has a large impact on the overall feel of a programming language. Great libraries feel like an extension of the language itself, and consistency across libraries elevates the overall development experience. To aid in the construction of great Swift libraries, one of the major goals for Swift 3 is to define a set of API design guidelines and to apply those design guidelines consistently.

The effort to define the Swift API Design Guidelines involves several major pieces that, together, are intended to provide a more cohesive feel to Swift development. Those major pieces are:

Swift API Design Guidelines: The actual API design guidelines are under active development. The latest draft of Swift API Design Guidelines is available.
Swift Standard Library: The entire Swift standard library is being reviewed and updated to follow the Swift API design guidelines. The actual work is being performed on the swift-3-api-guidelines branch of the Swift repository.
Imported Objective-C APIs: The translation of Objective-C APIs into Swift is being updated to make Objective-C APIs better match the Swift API design guidelines, using a variety of heuristics. The Better Translation of Objective-C APIs into Swift proposal describes how this transformation is done. Because this approach naturally involves a number of heuristics, we track its effects on the Cocoa and Cocoa Touch frameworks, as well as Swift code using those frameworks. The Swift 3 API Design Guidelines Review repository provides a way to see how this automatic translation affects Swift code that uses Cocoa and Cocoa Touch. Specific Objective-C APIs that translate poorly into Swift will then be annotated (for example, with NS_SWIFT_NAME) to improve the resulting Swift code. While this change primarily impacts Apple platforms (where Swift uses the Objective-C runtime), it also has a direct impact on the cross-platform Swift core libraries that provide the same APIs as Objective-C frameworks.
Swift Guideline Checking: Existing Swift code has been written to follow a variety of different coding styles, including the Objective-C Coding Guidelines for Cocoa. By leveraging the heuristics used to import Objective-C APIs, the Swift compiler can (optionally!) check for common API design patterns that don’t meet the Swift API Design Guidelines and suggest improvements.
Swift 2 to Swift 3 Migrator: The updates to the Swift standard library and the imported Objective-C APIs are source-breaking changes. This effort will involve the creation of a migrator to update Swift 2 code to use the Swift 3 APIs.

All of these major pieces are under active development. If you’re interested in following along, check out the Swift API design guidelines, the Swift standard library changes, the Objective-C API importer changes proposal and corresponding review repository, then join the discussion on the swift-evolution mailing list.

Swift 2.2 Release Process

2016-01-05T10:00:00-08:00

This post describes the goals, release process, and estimated schedule for Swift 2.2.

Swift 2.2 is the first offical release of Swift after Swift was released as open source. It will be a mostly source-compatible release with Swift 2.1, containing a large number of core improvements (e.g., bug fixes, enhancements to diagnostics, faster generated code) without many significant visible changes to the language itself. It is intended to be an intermediate point between Swift 2 and Swift 3, with Swift 3 containing more disruptive changes to both the language and Standard Library.

Swift on Linux will be included in this release. However it is still relatively new and has known caveats. Swift 2.2 will not include the Swift Core Libraries but will include LLDB and the REPL.

The Swift Package Manager is still early in development and will not be included in this release.

In addition to its Swift.org release, Swift 2.2 will ship in a future version of Xcode.

Logistics

Impacted Repositories

The following repositories will have a swift-2.2-branch to track sources as part of Swift 2.2 release:

Schedule

Swift 2.2 will branch from master on January 13, 2016. After January 13 the master branch will primarily track Swift 3 development. This specifically applies to the swift, swift-lldb, and swift-cmark repositories.
The swift-2.2-branch branches for the swift-llvm and swift-clang repositories were created earlier, from roughly LLVM revision 252576, to provide a longer period of time to stabilize the underlying LLVM platform. Those repositories will not be re-merging from master.
The final release date for Swift 2.2 is TBD. The intent is for Swift 2.2 to undergo a convergence period and will likely be released sometime in March to May of 2016.
Binary builds of the Swift 2.2 release branch will be made available alongside snapshots of Swift’s master development branch.
Swift 3 will follow a similar branching process as Swift 2.2 and will be announced a future date.

Getting Changes into Swift 2.2

Before January 13 all changes going into Swift’s master branch by definition will be a part of Swift 2.2.
Afterwards, the only language/API changes that will be considered for Swift 2.2 after the branch will be ones that make it more source compatible with Swift 2.1 or migration warnings for code that will be a build error in Swift 3. New features/extensions will not be accepted unless there is a really good reason to take them.
Criteria (as set by the release manager) for accepting changes will becoming increasingly restrictive over time as the release converges.
Contributions to the swift-2.2-branch for those without direct commit access can be initiated via a pull request. Pull requests should usually be used to pull in changes that are already in master unless those changes are specific to Swift 2.2 and will not be included in Swift 3. For example, a bug fix should first land in master and then pulled into swift-2.2-branch.
Core contributors with direct commit access will be able to directly cherry-pick or otherwise apply changes to swift-2.2-branch under the guidance of the respective code owner or release manager until a point in the schedule where the branch is under strict change control. An announcement will be made to the relevant component development mailing list (e.g., swift-dev) once the swift-2.2-branch is under stricter change management. At that point all changes must go through a nomination process via a pull request.

Release Management

The overall management of the release will be overseen by the following individuals, who will announce when stricter control of change goes into effect for the Swift 2.2 release as the release converges:

Ted Kremenek is the overall release manager for Swift 2.2.
Bob Wilson is the release manager for the LLVM and Clang components of Swift 2.2.
Kate Stone is the release manager for the LLDB component of Swift 2.2.

Please feel free to email swift-dev or Ted directly concerning any questions about the release management process.

Pull Requests

All pull requests nominating changes for inclusion in the swift-2.2-branch should include the following information:

Explanation: A description of the issue being fixed or enhancement being made. This can be brief, but it should be clear.
Scope: An assessement of the impact/importance of the change. For example, is the change a source-breaking language change, etc.
SR Issue: The SR if the change fixes/implements an issue/enhancement on bugs.swift.org.
Risk: What is the (specific) risk to the release for taking this change?
Testing: What specific testing has been done or needs to be done to further validate any impact of this change?

One or more code owners for the impacted components should review the change. Technical review can be delegated by a code owner or otherwise requested as deemed appropriate or useful.

Prior to the swift-2.2-branch going into restrictive change control (as announced by the release manager) a code owner is allowed to directly accept a pull request after it has gone through the aforementioned technical review. Once restrictive change control is in place, only the release manager is allowed to accept a pull request into swift-2.2-branch.

It's Coming: the Great Swift API Transformation

2016-01-29T00:00:00-08:00

Cocoa, the Swift standard library, maybe even your own types and methods—it’s all about to change, and you can help determine how.

Ever since before Swift was released, there’s been a style gap between Cocoa interfaces and APIs in the Swift standard library; lots of things just look different, often needlessly so. This is no mere aesthetic concern; non-uniformity and lack of predictability make everything harder, from coding to debugging to maintenance. Fortunately Swift developers created tons of great code in spite of that gap, and along the way, there evolved a sense of what “Swifty” code looks and feels like.

Informed by that experience, when looking at our APIs, it’s easy to see there’s room for improvement, both in the way the compiler imports Objective-C APIs—where the results just don’t seem quite comfortable in Swift—and in the Swift standard library, which lacks a level of regularity and coherence that Cocoa users have come to expect. So we at Apple decided to do something about it.

In order to converge Cocoa and the standard library, we needed a target to shoot for: a unified, written approach to API design that everyone could follow. We started by going back and questioning all our old assumptions. Existing guidelines were fantastic, but much of the material was geared to Objective-C, didn’t cover Swift-specific features such as default arguments, and more importantly, were not informed by the emergent sense of “Swiftiness” that we felt was so important to capture.

As we developed these guidelines we applied them to the standard library, all of Cocoa, and a couple of sample projects. We evaluated the results, refined, and repeated. Before Swift went open source, we’d have done this all behind closed doors, and presented you with the results in the next release, but a new era has dawned on Swift: it’s time to show the world what we’ve been up to. Here’s a tiny example of how code looks before transformation:

class UIBezierPath : NSObject, NSCopying, NSCoding { ... }
...
path.addLineToPoint(CGPoint(x: 100, y: 0))
path.fillWithBlendMode(kCGBlendModeMultiply, alpha: 0.7)

and after:

class UIBezierPath : Object, Copying, Coding { ... }
...
path.addLineTo(CGPoint(x: 100, y: 0))
path.fillWith(kCGBlendModeMultiply, alpha: 0.7)

We’ve put three parts of this proposed transformation up for public review in Swift’s evolution group: changes to how Cocoa is imported, changes to the surface of the standard library, and the API guidelines that tie this all together. Suggestions for improvement have already started coming in from participants, and we’re able to see how they affect APIs.

For example, one suggestion we’ve explored changes this call:

path.addArcWithCenter(
  origin, radius: 20.0, 
  startAngle: 0.0, endAngle: CGFloat(M_PI) * 2.0, clockwise: true)

into this:

path.addArc(
  center: origin, radius: 20.0, 
  startAngle: 0.0, endAngle: CGFloat(M_PI) * 2.0, clockwise: true)

Will we make this change? The jury is out, but this is the time to make your voice heard. The review period has been extended through Friday, February 5th. If you’d like to help shape the future of your language and frameworks, join the discussion. The proposals and associated review threads are here:

Continuous Integration now Available

2016-02-01T10:00:00-08:00

We are excited to announce that we have rolled out continuous integration (aka, CI) for the Swift project!

Our CI system is powered by Jenkins. For Apple’s platforms it builds and runs tests for macOS and the iOS simulator. For Linux it builds and runs tests for Ubuntu 14.04 and Ubuntu 15.10 (both for x86_64). In addition to using it for testing active branches, the CI system also produces the snapshots that are available for download from Swift.org.

The intent of the CI is to enable additional configurations to be added over time, especially in the cases where ports to other platforms or architectures reach a critical mass and support from the Swift development community.

CI is not only a powerful tool for monitoring the health of the Swift project, but can also be used as a part of reviewing changes before they land. To facilitate this, we have integrated testing within pull requests, allowing testing to occur before commits are made and without destabilizing the master branch. The results will be posted inline within the pull request. When someone makes a change that breaks a build, they will automatically be notified via email.

Testing Pull Requests

When a change is reviewed on a pull request, a member of the community with commit access can trigger testing of the pull request by the CI system. Tests can be triggered to run on macOS, Linux, or both platforms.

Testing status is then be posted inline with the pull request, showing that a test is in progress. You can click the “details” link to go directly to the status page for the test in progress.

When tests complete, the result is updated in the pull request.

If there are issues found during testing, you will get a link to the details of the failure.

In the near future, we will also be supporting running performance tests. We also welcome community involvement to help us expand testing to additional configurations.

Swift Benchmark Suite now Available

2016-02-08T10:00:00-08:00

Apple’s Swift Team is happy to announce that Swift’s benchmark suite is now open source.

The suite contains source code for benchmarks, libraries, and utilities designed to help track Swift performance and catch performance regressions before they are committed, including:

75 benchmarks covering a number of important Swift workloads
Libraries providing commonly needed benchmarking functions
A driver for running benchmarks and displaying performance metrics
A utility for comparing benchmark metrics across Swift versions

We look forward to working with the Swift community to make Swift as fast as possible!

Building and Running Benchmarks

Contributors to the Swift project are encouraged to run Swift’s benchmark suite against their changes before requesting pull requests in order to catch potential performance regressions. Instructions for building and running Swift benchmarks are available in swift/benchmark/README.md.

In the future, we are planning to add support to Swift’s continuous integration system for running benchmarks on pull requests.

Contributing Benchmarks and Improvements

Contributions to Swift’s benchmark suite are welcome! Pull requests for new benchmarks covering performance critical workloads, additions to benchmark helper libraries, and other improvements are encouraged. Please note that Swift’s benchmark suite shares the Swift project’s license, so we are unable to accept Swift ports of benchmarks covered under other licenses. Additional information about the suite and instructions on adding benchmarks are available in swift/benchmark/README.md.

Expanding Commit Access

2016-02-29T00:00:00-08:00

Now that the Swift Continuous Integration system is established and proven, we’d like to grant commit access on a more frequent basis to project contributors who have established a track record of good contributions. If you would like commit access, please send an email to the code owners list with a list of 5 non-trivial pull requests that we accepted without modifications.

For more details about what it means to have commit access, please see the Contributing Code section.

Swift 2.2 Released!

2016-03-21T05:00:00-07:00

We are very pleased to announce the release of Swift 2.2! This is the first official release of Swift since it was open-sourced on December 3, 2015. Notably, the release includes contributions from 212 non-Apple contributors — changes that span from simple bug fixes to enhancements and alterations to the core language and Swift Standard Library.

Language Changes

Swift 2.2 is a minor language release that is mostly source-compatible with Swift 2.1. It contains the following language changes that went through the Swift’s evolution process:

Beyond these language changes Swift 2.2 also contains numerous bug fixes, enhancements to diagnostics, and produces even faster-running code.

The Swift Package Manager is still early in development and is not included in this release.

Documentation

An updated version of The Swift Programming Language for Swift 2.2 is now available on Swift.org. It is also available for free on Apple’s iBooks store.

Platforms

Linux (Ubuntu 14.04 and Ubuntu 15.10)

Swift 2.2 includes support for Swift on Linux. The Linux port is still relatively new and in this release does not include the Swift Core Libraries (which will appear in Swift 3). The port does, however, include LLDB and the REPL.

Official binaries for Ubuntu 14.04 and Ubuntu 15.10 are available for download.

Apple (Xcode)

For development on Apple’s platforms, Swift 2.2 ships as part of Xcode 7.3.

Sources

Development on Swift 2.2 was tracked in the swift-2.2-branch on the following repositories on GitHub:

The tag swift-2.2-RELEASE designates the specific revisions in those repositories that make up the final version of Swift 2.2.

The swift-2.2-branch will remain open — but under the same release management process — to accumulate changes for a potential future bug-fix “dot” release.

New Features in Swift 2.2

2016-03-30T01:00:00-07:00

Swift 2.2 brings new syntax, new features, and some deprecations too. It is an interim release before Swift 3 comes later this year with even bigger changes, and the changes in Swift 2.2 align with the broader goals of Swift 3 to focus on gradually stabilizing the core language and Standard Library by adding missing features, refining what is already there, and removing what is no longer needed in the language. All changes in Swift 2.2 went through the community-driven Swift evolution process — where over 30 proposals have been submitted, reviewed, and accepted since Swift was open-sourced a few months ago.

The changes in Swift 2.2 will have a direct impact on your code, and this article will walk you through what has changed and why, along with code examples to help you migrate quickly to the new Swift 2.2 syntax.

As a reminder, “deprecation” means that a function or language feature is no longer recommended for use and will be removed entirely at a later date. In practice that means Swift will issue a compiler warning today, and a compiler error in the future — likely Swift 3.

Compile-time Swift version checks

Swift’s continuous march forward can occasionally be hard for app developers to keep up with, but it’s even harder for developers of libraries — if you have thousands of people using your library, you might need to support more than one version of Swift to ensure everyone can use your work no matter what version they are on.

Swift 2.2 introduces a new compiler directive that makes cross-version compatibility a cinch: you can now specify blocks of code that should be read only if the compiler supports a specific Swift language version. For example:

#if swift(>=3.0)
print("Running Swift 3.0 or later")
#else
print("Running Swift 2.2 or earlier")
#endif

This is different from the #available syntax introduced in Swift 2 because that was a runtime check — this new feature is compile time, so code that fails the language version check is effectively invisible. You could write code like this if you wanted to:

#if swift(>=3.0)
print("Running Swift 3.0 or later")
#else
BRING BACK WASH HE WAS MY FAVORITE
#endif

As long as the Swift compiler targets 3.0 or greater, that will compile just fine because the message in capital letters is ignored by the compiler.

A word of warning: this feature is not useable at this time, because a Swift 2.1 compiler will choke on #if swift(>=2.2) — it has no idea what that means. However, once Swift 3.0 becomes available, and for all future versions, compile-time Swift version checks will be a useful addition to your toolkit.

For more information, see the Swift Evolution proposal for this change.

Compile-time checked selectors

In Swift 2.1, code like the below would compile with no problems:

override func viewDidLoad() {
    super.viewDidLoad()

    navigationItem.rightBarButtonItem =
        UIBarButtonItem(barButtonSystemItem: .Add, target: self,
                        action: "addNewFireflyRefernce")
}

func addNewFireflyReference() {
    gratuitousReferences.append("We should start dealing in black-market beagles.")
}

The code itself is syntactically sound, but the app will crash because the navigation bar button calls a method addNewFireflyRefernce() — it’s missing one of the Es in “reference”. These kinds of simple typos could easily introduce bugs, so Swift 2.2 deprecates using strings for selectors and instead introduces new syntax: #selector.

Using #selector will check your code at compile time to make sure the method you want to call actually exists. Even better, if the method doesn’t exist, you’ll get a compile error: Xcode will refuse to build your app, thus banishing to oblivion another possible source of bugs.

Here is the previous code example rewritten using #selector:

override func viewDidLoad() {
    super.viewDidLoad()

    navigationItem.rightBarButtonItem =
        UIBarButtonItem(barButtonSystemItem: .Add, target: self,
                        action: #selector(addNewFireflyRefernce))
}

func addNewFireflyReference() {
    gratuitousReferences.append("Curse your sudden but inevitable betrayal!")
}

When that code is built, the compiler will send back the error “Use of unresolved identifier ‘addNewFireflyRefernce’” — shiny!

For more information, see the Swift Evolution proposal or read the swift-evolution-announce post detailing the rationale.

More keywords as argument labels

Swift has a lot of keywords: those little things like class, func, let, and public that have special meaning and cannot be used as identifiers. Swift has always allowed you to use keywords as argument labels, but only if you placed them in backticks like this:

func visitCity(name: String, `in` state: String) {
    print("I'm going to visit \(name) in \(state)")
}

visitCity("Nashville", `in`: "Tennessee")

As of Swift 2.2, any keyword can be used as an argument label, with the exception of inout, var, and let. If you have code that used keywords in backticks, you’ll get an Xcode Fix-it to remove them. So, code like this is now possible:

func visitCity(name: String, in state: String) {
    print("I'm going to visit \(name) in \(state)")
}

visitCity("Nashville", in: "Tennessee")

For more information, see the Swift Evolution proposal for this change.

Tuple comparison is built-in

Tuples are a fundamental data type in Swift, and bring a number of benefits — not least being able to return multiple values from functions. Swift 2.2 introduces the ability to compare two tuples for equality, which means it will check each element in one tuple against the matching element in another, and report true if all elements match.

For example, the below code will print “No match”:

let singer = (first: "Taylor", last: "Swift")
let alien = (first: "Justin", last: "Bieber")

if singer == alien {
    print("They match! That explains why you never see them together…")
} else {
    print("No match.")
}

Swift 2.2 tuple comparison works up to arity 6, which is a fancy way of saying that tuples can be compared as long as they contain no more than six elements.

One warning: Swift 2.2 will ignore your element names when checking for equality, so singer and bird will be considered equal in the code below:

let singer = (first: "Taylor", last: "Swift")
let bird = (name: "Taylor", breed: "Swift")

if singer == bird {
    print("This explains why she sings so well.")
} else {
    print("No match.")
}

For more information, see the Swift Evolution proposal for this change.

Tuple splat syntax is deprecated

Staying with tuples for a moment longer, Swift 2.2 deprecates a feature that was so rarely used I’m only mentioning it because of the marvelous name. In Swift 2.1 and earlier it was possible to use a carefully crafted tuple to fill the parameters of a function. So, if you had a function that took two parameters, you could call it with a two-element tuple as long as the tuple had the correct types and element names. For example:

func describePerson(name: String, age: Int) {
    print("\(name) is \(age) years old")
}

let person = ("Malcolm Reynolds", age: 49)
describePerson(person)

This syntax — affectionately called “tuple splat syntax” — is the antithesis of idiomatic Swift’s self-documenting, readable style, and so it’s deprecated in Swift 2.2.

For more information, see the Swift Evolution proposal or read the swift-evolution-announce post detailing the rationale.

C-style `for` loops are deprecated

Even though Swift has several idiomatic loop options, C-style for loops were still part of the language and occasionally used. For example:

for var i = 0; i < 10; i++ {
    print(i)
}

These have been deprecated in Swift 2.2 and will be removed entirely in Swift 3.0 — one more step towards never typing a semi-colon again.

If you use Xcode, you may be offered a Fix-it that will convert your C-style for loops into modern Swift. In the previous case, the result uses a range like this:

for i in 0 ..< 10 {
    print(i)
}

However, Fix-it’s capabilities are limited, so you will need to do some work yourself. For example, the two loops below are ones that Fix-it will not help you with at this time:

for var i = 10; i > 0; i-- {
    print(i)
}

for var i = 0; i < 10; i += 2 {
    print(i)
}

In the first case, you should create a reverse range using (1...10).reverse(). This is not the same as writing i in 10...1, which will compile but crash at runtime. In the second case, you should use stride(to:by:) to count in twos. So, the correct way to rewrite both loops for Swift 2.2 is like this:

for i in (1...10).reverse() {
    print(i)
}

for i in 0.stride(to: 10, by: 2) {
    print(i)
}

For more information, see the Swift Evolution proposal or read the swift-evolution-announce post detailing the rationale.

`++` and `--` are deprecated

If you were using C-style for loops, this next change might surprise you even more: ++ and -- are also deprecated, both as prefix and postfix operators. This means that code such as for var i = 0; i < 10; i++ contains not one but two deprecations, which is quite remarkable even in the fast-moving Swift world.

This change means that all the code below is now deprecated, and will stop working entirely in Swift 3:

i++
i--
++i
--i
i = i++

You will instead need to use i += 1 or i -= 1, and Xcode will offer you Fix-its for each of the examples above. In the interests of full disclosure: the Fix-it for i = i++ will give you a compiler error, which is not really a surprise — what is i = i++ supposed to do anyway?

There is no single reason for this change. Instead, it’s a number of small reasons that add up, not least:

Writing i++ was only slightly shorter than writing i += 1.
If a newcomer to Swift was not already familiar with ++ and -- they just steepened the learning curve.
C-style loops — a common place where ++ and -- are used — are also being deprecated.
Using the result of these operators depends on whether they are used prefix or postfix, which can cause confusion.

There’s a quote in the Swift Evolution proposal for this change that sums up the rationale concisely: these fail the metric of “if we didn’t already have these, would we add them to Swift 3?” [1]

For more information, see the Swift Evolution proposal for this change.

`var` parameters are deprecated

Prior to Swift 2.2, function parameters could be declared as var if you wanted to modify them inside the function. For example:

func greet(var name: String) {
    name = name.uppercaseString
    print("Hello, \(name)!")
}

var name = "Taylor"
greet(name)
print("After function, name is \(name)")

While this was a helpful shortcut, it did add some extra confusion: does that final print() statement output “Taylor” or “TAYLOR”? This was made even more confusing by the presence of the inout keyword: using inout rather than var in that example, then adding a single ampersand, produces this code:

func greet(inout name: String) {
    name = name.uppercaseString
    print("Hello, \(name)!")
}

var name = "Taylor"
greet(&name)
print("After function, name is \(name)")

When run, the var example produces different output to the inout example, because changes to var parameters apply only inside the function whereas changes to inout parameters affect the original value directly.

In Swift 2.2, this confusion is cleared up by deprecating the var keyword for function parameters, ahead of its removal in Swift 3.0. If you want to replicate the old behavior, simply create your own copy inside the function like this:

func greet(name: String) {
    let uppercaseName = name.uppercaseString
    print("Hello, \(uppercaseName)!")
}

For more information, see the Swift Evolution proposal or read the swift-evolution-announce post detailing the rationale.

Renamed debug identifiers

The Swift compiler automatically provides some symbols that are useful when debugging. Previously these were in “screaming snake case”, so __FILE__ would be replaced with the name of the current Swift file, __LINE__ with the line number and so on. In Swift 2.2 those old identifiers are deprecated and replaced with #file, #line, #column, and #function, which introduces “a convention where # means invoke compiler substitution logic here.” [2]

Here’s an example demonstrating the old and new syntax:

func visitCity(name: String, in state: String) {
    // old - deprecated!
    print("This is on line \(__LINE__) of \(__FUNCTION__)")

    print("I'm going to visit \(name) in \(state)")

    // new - shiny!
    print("This is on line \(#line) of \(#function)")
}

As with many other changes, Xcode has a Fix-it that will update your code correctly.

For more information, see the Swift Evolution proposal or read the swift-evolution-announce post detailing the rationale.

And there’s more…

This post has covered the changes that are likely to affect most developers, but other smaller changes have been introduced alongside improved compiler messages and performance enhancements. Click here for the official release notes, where you can find links to full discussions on the changes as well as install instructions for Linux.

Swift 3.0 Release Process

2016-05-06T06:00:00-07:00

This post describes the goals, release process, and estimated schedule for Swift 3.0.

Swift 3.0 is a major release that is not source-compatible with Swift 2.2. It contains fundamental changes to the language and Swift Standard Library. A comprehensive list of implemented changes for Swift 3.0 can be found on the Swift evolution site.

Swift 3.0 is also the first release to include the Swift Package Manager. While the Swift Package Manager is still early in its development, it supports the development and distribution of cross-platform Swift packages. The Swift Package Manager will be available on both Darwin and Linux.

For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries.

Swift 3.0 is expected to be released sometime in late 2016. In addition to its Swift.org release, Swift 3.0 will ship in a future version of Xcode.

Developer Previews

Swift 3.0 will have a series of developer previews (i.e., “seeds” or “betas”) that provide qualified and converged builds of Swift 3. The goal is to provide users with more stable and qualified Swift binaries that they can download and try out (and file bugs against) instead of just grabbing the latest snapshot of master.
The cadence between Developer Previews will likely be irregular, but likely every 4-6 weeks. They will be partially driven by the volume of change going into master and how much time is needed to stabilize a developer preview branch.
Swift 3.0 will be declared “GM” from the last developer preview branch.
Content going into developer previews will be managed by the appropriate release manager (see below).

Getting Changes into Swift 3.0

Branches

master: Development of Swift 3.0 happens in master. All changes going in master will be part of the final Swift 3.0 release until the last developer preview branch is created. At that point master tracks development for future Swift releases.
swift-3.0-preview-<X>-branch: Branches for developer previews will be created from master. All changes to those branches will need to be submitted via pull requests that initiate testing on continuous integration. The release manager for the given repository approves merging a pull request into the developer preview branch.
swift-3.0-branch: The last developer preview branch created from master will be called swift-3.0-branch. This will be the final “release branch”.

Philosophy on Taking Changes into Swift 3.0

As Swift 3.0 converges only changes that align with the core goals of the release will be considered.
Source-breaking changes to the language will be considered on a case-by-case basis.
All language and API changes for Swift 3.0 will go through the Swift Evolution process.
Criteria — as set by the release manager — for accepting changes will becoming increasingly restrictive over time as the release converges. The same policy applies to developer preview branches, which are essentially mini-releases.

Schedule

The first developer preview branch swift-3.0-preview-1-branch will be created from master on May 12. It will be released 4-6 weeks later.
The date for creating the last developer preview branch — swift-3.0-branch — has not yet been established. When that date is determined the plan will be communicated both on swift-dev and by updating this post.

Impacted Repositories

The following repositories will have swift-3.0-preview-<X>-branch/swift-3.0-branch branches to track sources as part of Swift 3.0 release:

The following repositories will only have a swift-3.0-branch instead of developer preview branches, as they have already effectively converged:

Release Managers

The overall management of the release will be overseen by the following individuals, who will announce when stricter control of change goes into effect for the Swift 3.0 release as the release converges:

Ted Kremenek is the overall release manager for Swift 3.0.
Frédéric Riss is the release manager for swift-llvm and swift-clang.
Kate Stone is the release manager for swift-lldb.
Tony Parker is the release manager for swift-corelibs-foundation.
Daniel Steffen is the release manager for swift-corelibs-libdispatch.
Mike Ferris is the release manager for swift-corelibs-xctest.
Rick Ballard is the release manager for swift-package-manager.

Please feel free to email swift-dev or Ted Kremenek directly concerning any questions about the release management process.

Pull Requests for Developer Previews

All pull requests nominating changes for inclusion in developer preview branches should include the following information:

Explanation: A description of the issue being fixed or enhancement being made. This can be brief, but it should be clear.
Scope: An assessment of the impact/importance of the change. For example, is the change a source-breaking language change, etc.
SR Issue: The SR if the change fixes/implements an issue/enhancement on bugs.swift.org.
Risk: What is the (specific) risk to the release for taking this change?
Testing: What specific testing has been done or needs to be done to further validate any impact of this change?

One or more code owners for the impacted components should review the change. Technical review can be delegated by a code owner or otherwise requested as deemed appropriate or useful.

All change going into developer preview branches must go through pull requests that are accepted by the corresponding release manager.

Swift 2.3

2016-06-12T19:00:00-07:00

We are pleased to announce Swift 2.3!

Swift 2.3 is a minor update from Swift 2.2.1. The primary difference between Swift 2.2.1 and Swift 2.3 is that it is intended to be paired with Apple’s macOS 10.12, iOS 10, watchOS 3, and tvOS 10 SDKs. It also updates the underlying LLVM and Clang versions to match with those in the Swift 3 compiler.

Sources

Sources for Swift 2.3 are available in the swift-2.3-branch branch on GitHub.

Downloads

Apple (Xcode)

Swift 2.3 is available for free as part of Xcode 8.

Linux (Ubuntu 14.04 and Ubuntu 15.10)

Official binaries for Linux will be available shortly after the upgrade to the continuous integration system (which produces the binaries). Note that for Linux, Swift 2.2.1 and Swift 2.3 are nearly identical. This post will be updated once binaries are available.

Swift 3.0 Preview 1 Released!

2016-06-13T05:00:00-07:00

We are very pleased to announce Developer Preview 1 of Swift 3.0!

As described in the Swift 3.0 Release Process, developer previews (i.e., “seeds” or “betas”) provide qualified builds of Swift 3 that are more stable than just grabbing the latest snapshot of master (i.e., tip-of-trunk development). Developer previews capture Swift 3 as a work-in-progress and should not be considered the final version of Swift 3 unless otherwise stated.

Implemented Swift Evolution Proposals

The following Swift Evolution proposals are newly implemented in Swift 3.0 Preview 1:

Downloads

Apple (Xcode)

Swift 3.0 Preview 1 is available for free as part of Xcode 8 beta 1.

Linux (Ubuntu 14.04 and Ubuntu 15.10)

Official binaries for Ubuntu 14.04 and Ubuntu 15.10 are available for download on Swift.org.

Documentation

An updated version of The Swift Programming Language for Swift 3.0 is now available on Swift.org. It is also available for free on Apple’s iBooks store.

Foundation and Linux (Core Libraries)

Not all of the NS prefix removal changes have propagated to the Core Libraries implementation of Foundation APIs. This should be resolved in a future beta.

Migrating to Swift 3

Swift 3 is a source-breaking release over Swift 2.2.1. It contains many syntactic refinements and improvements, but also a huge number of changes for how Objective-C APIs import into Swift due to SE-0005. Please consult the migration guide for guidance and tips for migrating to Swift 3.

Xcode Playground Support

2016-07-07T06:00:00-07:00

We are delighted to introduce Xcode Playground Support as part of the Swift open source community!

Swift developers can approach the language in many different ways. In addition to the traditional command-line compiler and interactive REPL one of the earliest experiences for many developers was through the introduction of playgrounds in Xcode. Prior to Swift 3.0 and Xcode 8 this was only possible with the version of Swift included with Xcode. The Xcode Playground Support project enables building a Swift toolchain that includes everything necessary to integrate with the Xcode 8 playground experience. Playground Support will be included in corresponding snapshots. Download a snapshot, install it, and select the toolchain to work with the latest Swift features in Xcode playgrounds.

Swift 3.0 Released!

2016-09-13T05:00:00-07:00

Swift 3.0, the first major release of Swift since it was open-sourced, is now officially released! Swift 3 is a huge release containing major improvements and refinements to the core language and Standard Library, major additions to the Linux port of Swift, and the first official release of the Swift Package Manager.

Language Changes

Swift 3.0 is a major language release. It is not source-compatible with Swift 2.2 and 2.3. It contains the following language changes that went through the Swift’s evolution process:

Migrating to Swift 3

Swift 3 is a source-breaking release, largely due to the changes in SE-0005 and SE-0006. These changes not only impact the names of the Standard Library APIs, but also completely change how Objective-C APIs (particularly from Cocoa) import into Swift. Many of the changes are largely mechanical, but they can be numerous in a typical Swift project.

To help with moving to Swift 3, Xcode 8.0 contains a code migrator that can automatically handle many of the need source changes. There is also a migration guide available to guide you through many of the changes — especially through the ones that are less mechanical and require more direct scrutiny.

Documentation

An updated version of The Swift Programming Language for Swift 3.0 is now available on Swift.org. It is also available for free on Apple’s iBooks store.

Platforms

Linux (Ubuntu 14.04 and Ubuntu 15.10)

The Linux port now includes the Swift Core Libraries and the Swift Package Manager.

Official binaries for Ubuntu 14.04 and Ubuntu 15.10 are available for download.

Apple (Xcode)

For development on Apple’s platforms, Swift 3.0 ships as part of Xcode 8.0.

Sources

Development on Swift 3.0 was tracked in the swift-3.0-branch on the following repositories on GitHub:

The tag swift-3.0-RELEASE designates the specific revisions in those repositories that make up the final version of Swift 3.0.

The swift-3.0-branch will remain open, but under the same release management process, to accumulate changes for a potential future bug-fix “dot” release.

Whole-Module Optimization in Swift 3

2016-10-21T03:00:00-07:00

Whole-module optimization is an optimization mode of the Swift compiler. The performance win of whole-module optimization heavily depends on the project, but it can be up to two or even five times.

Whole-module optimization can be enabled with the -whole-module-optimization (or -wmo) compiler flag, and in Xcode 8 it is turned on by default for new projects. Also the Swift Package Manager compiles with whole-module optimizations in release builds.

So what is it about? Let’s first look at how the compiler works without whole-module optimizations.

Modules and how to compile them

A module is a set of Swift files. Each module compiles down to a single unit of distribution—either a framework or an executable. In single-file compilation (without -wmo) the Swift compiler is invoked for each file in the module separately. Actually, this is what happens behind the scenes. As a user you don’t have to do this manually. It is automatically done by the compiler driver or the Xcode build system.

After reading and parsing a source file (and doing some other stuff, like type checking), the compiler optimizes the Swift code, generates machine code and writes an object file. Finally the linker combines all object files and generates the shared library or executable.

In single-file compilation the scope of the compiler’s optimizations is just a single file. This limits cross-function optimizations, like function inlining or generic specialization, to functions which are called and defined in the same file.

Let’s look at an example. Let’s assume one file of our module, named utils.swift, contains a generic utility data structure Container<T> with a method getElement and this method is called throughout the module, for example in main.swift.

main.swift:

func add (c1: Container<Int>, c2: Container<Int>) -> Int {
  return c1.getElement() + c2.getElement()
}

utils.swift:

struct Container<T> {
  var element: T

  func getElement() -> T {
    return element
  }
}

When the compiler optimizes main.swift it does not know how getElement is implemented. It just knows that it exists. So the compiler generates a call to getElement. On the other hand, when the compiler optimizes utils.swift, it does not know for which concrete types the function is called. So it can only generate the generic version of the function which is much slower than code which is specialized for a concrete type.

Even the simple return statement in getElement needs a lookup in the type’s metadata to figure out how to copy the element. It could be a simple Int, but it could also be a larger type, even involving some reference counting operations. The compiler just doesn’t know.

Whole-module optimization

With whole-module optimization the compiler can do a lot better. When compiling with the -wmo option, the compiler optimizes all files of a module as a whole.

This has two big advantages. First, the compiler sees the implementation of all functions in a module, so it can perform optimizations like function inlining and function specialization. Function specialization means that the compiler creates a new version of a function which is optimized for a specific call-context. For example, the compiler can specialize a generic function for concrete types.

In our example, the compiler produces a version of the generic Container which is specialized for the concrete type Int.

struct Container {
  var element: Int

  func getElement() -> Int {
    return element
  }
}

Then the compiler can inline the specialized getElement function into the add function.

func add (c1: Container<Int>, c2: Container<Int>) -> Int {
  return c1.element + c2.element
}

This compiles down to just a few machine instructions. That’s a big difference compared to the single-file code where we had two calls to the generic getElement function.

Function specialization and inlining across files are just examples of optimizations the compiler is able to do with whole-module optimizations. Even if the compiler decides not to inline a function, it helps a lot if the compiler sees the implementation of the function. For example it can reason about its behavior regarding reference counting operations. With this knowledge the compiler is able to remove redundant reference counting operations around a function call.

The second important benefit of whole-module optimization is that the compiler can reason about all uses of non-public functions. Non-public functions can only be used within the module, so the compiler can be sure to see all references to such functions. What can the compiler do with this information?

One very basic optimization is the elimination of so called “dead” functions and methods. These are functions and methods which are never called or otherwise used. With whole-module optimizations the compiler knows if a non-public function or method is not used at all, and if that’s the case it can eliminate it. So why would a programmer write a function, which is not used at all? Well, this is not the most important use case for dead function elimination. Often functions become dead as a side-effect of other optimizations.

Let’s assume that the add function is the only place where Container.getElement is called. After inlining getElement, this function is not used anymore, so it can be removed. Even if the compiler decides to not inline getElement, the compiler can remove the original generic version of getElement, because the add function only calls the specialized version.

Compile time

With single-file compilation the compiler driver starts the compilation for each file in a separate process, which can be done in parallel. Also, files which were not modified since the last compilation don’t need to be recompiled (assuming all dependencies are also unmodified). That’s called incremental compilation. All this saves a lot of compile time, especially if you only make a small change. How does this work in whole-module compilation? Let’s look at how the compiler works in whole-module optimization mode in more detail.

Internally the compiler runs in multiple phases: parser, type checking, SIL optimizations, LLVM backend.

Parsing and type checking is very fast in most cases, and we expect it to get even faster in subsequent Swift releases. The SIL optimizer (SIL stands for “Swift Intermediate Language”) performs all the important Swift-specific optimizations, like generic specialization, function inlining, etc. This phase of the compiler typically takes about one third of the compilation time. Most of the compilation time is consumed by the LLVM backend which runs lower-level optimizations and does the code generation.

After performing whole-module optimizations in the SIL optimizer the module is split again into multiple parts. The LLVM backend processes the split parts in multiple threads. It also avoids re-processing of a part if that part didn’t change since the previous build. So even with whole-module optimizations, the compiler is able to perform a big part of the compilation work in parallel (multi-threaded) and incrementally.

Conclusion

Whole-module optimization is a great way to get maximum performance without having to worry about how to distribute Swift code across files in a module. If optimizations, like described above, kick in at a critical code section, performance can be up to five times better than with single-file compilation. And you get this high performance with much better compile times than typical to monolithic whole-program optimization approaches.

Server APIs Work Group

2016-10-25T02:00:00-07:00

Since Swift became available on Linux there has been a huge amount of interest in using Swift on the server, resulting in the emergence of a number of Web Frameworks, including Kitura, Vapor, Perfect, and Zewo, along with many others. As an important part of the Swift ecosystem, and one that we are keen to foster, we are today announcing the formation of the Server APIs work group.

The work group provides the framework for participants in the the community with an interest in building server applications and frameworks to come together to work on providing new Swift APIs. These APIs will provide low level “server” functions as the basic building blocks for developing server-side capabilities, removing the reliance on interfacing with generally platform specific C libraries for these functions. This will enable more developers to create frameworks and server applications using pure-Swift code, without the need to also have systems programming skills and knowledge of multiple platforms.

The work group will initially be looking at APIs for networking, security, and HTTP/WebSocket parsing, with the goal of making it possible for anyone to build a simple, secure, HTTP server, or to start to build other server frameworks like pub/sub message brokers.

For more information, take a look at the Server APIs project page.

Swift 3.1 Release Process

2016-12-09T02:00:00-08:00

This post describes the goals, release process, and estimated schedule for Swift 3.1.

Swift 3.1 is intended to be source compatible with Swift 3.0. It will contain a few additive enhancements to the core language as well as improvements to the Swift Package Manager, Swift on Linux, and general quality improvements to the compiler and Standard Library.

Swift 3.1 is intended to be released in the spring of 2017.

Source Compatibility

It is a strong goal that the vast majority of sources that built with the Swift 3.0 compiler continue to build with the Swift 3.1 compiler. The exception will be bug fixes to the compiler that cause it to reject code that should never have been accepted in the first place. These cases should be relatively rare in practice.

A description of the intent for source compatibility for Swift releases can be found on a thread on the swift-evolution mailing list.

Please file bug reports if you encounter cases where the Swift 3.1 compiler unexpectedly rejects code that previously compiled with the Swift 3.0 compiler.

Snapshots of Swift 3.1

Previous releases of Swift have had “Developer Previews”, e.g. “Preview 1”, “Preview 2”, etc., that represent stabilized snapshots of a Swift release as it converges. Developer previews have often been irregularly spaced apart, and have sometimes not provided enough granularity for the Swift community to try out new features or verify bug fixes in a release as it converges.

For Swift 3.1 there will instead be daily downloadable snapshots of the release branch. Snapshots will be produced as part of continuous integration testing. The cadence of downloadable snapshots will thus be more frequent and granular. Snapshots will be posted daily, assuming tests are passing.

Once Swift 3.1 is released, official final builds will also be posted in addition to the snapshots.

Getting Changes into Swift 3.1

Swift 3.1 is intended to be limited in scope, with the desire to move focus early in 2017 to the development of Swift 4. To meet this goal, Swift 3.1 will include changes in mainline development (i.e. the master branch) only until January 16. After that date there will be a “bake” period in which only select, critical fixes will go into the swift-3.1-branch and move master on to Swift 4 development.

Branches

master: With the exception of the swift-llvm and swift-clang repositories (see Impacted Repositories), development of Swift 3.1 happens in master. All changes going in master will be part of the final Swift 3.1 release until January 16. At that point master tracks development for Swift 4.
swift-3.1-branch: Release management for Swift 3.1 happens on the swift-3.1-branch. All Swift 3.1 snapshots are built from this branch, and Swift 3.1 will GM from this branch as well.

Operationally, master will be regularly merged into swift-3.1-branch approximately every two weeks until January 16. The two week window provides a buffer between hot development on master and a curated release branch. Changes may be cherry-picked (via pull requests) into swift-3.1-branch between merges of master.

A notable exception to this plan is the swift-package-manager, which will merge from master into the swift-3.1-branch daily.

Philosophy on Taking Changes into Swift 3.1

Source compatibility with Swift 3.0 is a top priority.
As Swift 3.1 converges only changes that align with the core goals of the release will be considered.
All language and API changes for Swift 3.1 will go through the Swift Evolution process.
Major work for Swift 3.1 should orient around the January 16 date, but changes can still land in 3.1 afterwards per the judgement of the release manager. As the release converges, the criteria for pulling changes into 3.1 will become increasingly restrictive.

Impacted Repositories

The following repositories will have a swift-3.1-branch branch to track sources as part of Swift 3.1 release:

Note that the swift-llvm and swift-clang repositories have already branched swift-3.1-branch from master and will not rebranch again.

Release Managers

The overall management of the release will be overseen by the following individuals, who will announce when stricter control of change goes into effect for the Swift 3.1 release as the release converges:

Ted Kremenek is the overall release manager for Swift 3.1.
Frédéric Riss is the release manager for swift-llvm and swift-clang.
Jason Gosnell is the release manager for swift-lldb.
Tony Parker is the release manager for swift-corelibs-foundation.
Daniel Steffen is the release manager for swift-corelibs-libdispatch.
Brian Croom is the release manager for swift-corelibs-xctest.
Rick Ballard is the release manager for swift-package-manager.

Please feel free to email swift-dev or Ted Kremenek directly concerning any questions about the release management process.

Pull Requests for Release Branch

All pull requests nominating changes for inclusion in the release branch should include the following information:

Explanation: A description of the issue being fixed or enhancement being made. This can be brief, but it should be clear.
Scope: An assessment of the impact/importance of the change. For example, is the change a source-breaking language change, etc.
SR Issue: The SR if the change fixes/implements an issue/enhancement on bugs.swift.org.
Risk: What is the (specific) risk to the release for taking this change?
Testing: What specific testing has been done or needs to be done to further validate any impact of this change?

One or more code owners for the impacted components should review the change. Technical review can be delegated by a code owner or otherwise requested as deemed appropriate or useful.

All change going into the swift-3.1-branch (outside changes being merged in automatically from master) must go through pull requests that are accepted by the corresponding release manager.

Swift.org

The Swift.org Blog

Projects

Swift Package Manager

Core Libraries

Swift.org Website

The Swift Linux Port

Swift 3 API Design Guidelines

Swift 2.2 Release Process

Logistics

Impacted Repositories

Schedule

Getting Changes into Swift 2.2

Release Management

Pull Requests

It's Coming: the Great Swift API Transformation

Continuous Integration now Available

Testing Pull Requests

Swift Benchmark Suite now Available

Building and Running Benchmarks

Contributing Benchmarks and Improvements

Expanding Commit Access

Swift 2.2 Released!

Language Changes

Documentation

Platforms

Linux (Ubuntu 14.04 and Ubuntu 15.10)

Apple (Xcode)

Sources

New Features in Swift 2.2

Compile-time Swift version checks

Compile-time checked selectors

More keywords as argument labels

Tuple comparison is built-in

Tuple splat syntax is deprecated

C-style for loops are deprecated

++ and -- are deprecated

var parameters are deprecated

Renamed debug identifiers

And there’s more…

Swift 3.0 Release Process

Developer Previews

Getting Changes into Swift 3.0

Branches

Philosophy on Taking Changes into Swift 3.0

Schedule

Impacted Repositories

Release Managers

Pull Requests for Developer Previews

Swift 2.3

Sources

Downloads

Apple (Xcode)

Linux (Ubuntu 14.04 and Ubuntu 15.10)

Swift 3.0 Preview 1 Released!

Implemented Swift Evolution Proposals

Downloads

Apple (Xcode)

Linux (Ubuntu 14.04 and Ubuntu 15.10)

Documentation

Foundation and Linux (Core Libraries)

Migrating to Swift 3

Xcode Playground Support

Swift 3.0 Released!

Language Changes

Migrating to Swift 3

Documentation

Platforms

Linux (Ubuntu 14.04 and Ubuntu 15.10)

Apple (Xcode)

Sources

Whole-Module Optimization in Swift 3

Modules and how to compile them

Whole-module optimization

Compile time

Conclusion

Server APIs Work Group

Swift 3.1 Release Process

Source Compatibility

Snapshots of Swift 3.1

C-style `for` loops are deprecated

`++` and `--` are deprecated

`var` parameters are deprecated