Swift Changelog

What's new in Swift 5.5

Sep 21, 2021

Swift 5.5 is a massive release, which includes newly introduced language capabilities for concurrency, including async/await, structured concurrency, and Actors.
Swift Evolution proposals:
A number of changes went through the Swift Evolution process for inclusion in Swift 5.5:
SE-0291 Package Collections
SE-0293 Extend Property Wrappers to Function and Closure Parameters
SE-0295 Codable synthesis for enums with associated values
SE-0296 Async/await
SE-0297 Concurrency Interoperability with Objective-C
SE-0298 Async/Await: Sequences
SE-0299 Extending Static Member Lookup in Generic Contexts
SE-0300 Continuations for interfacing async tasks with synchronous code
SE-0304 Structured concurrency
SE-0306 Actors
SE-0307 Allow interchangeable use of CGFloat and Double types
SE-0308 if for postfix member expressions
SE-0310 Effectful Read-only Properties
SE-0311 Task Local Values
SE-0313 Improved control over actor isolation
SE-0314 AsyncStream and AsyncThrowingStream
SE-0316 Global actors
SE-0317 async let bindings
SE-0319 Conform Never to Identifiable

New in Swift 5.4 (Apr 27, 2021)

Language Updates:
Swift 5.4 includes the following new language features:
Support for multiple variadic parameters in functions, subscripts and initializers (SE-0284)
Extend implicit member syntax (SE-0287)
Result builders (SE-0289)
Local functions supporting overloading
Property wrappers for local variables
To prepare the way for a new concurrency model, the compiler now emits a warning and fix-it for unqualified uses of await as an identifier. Those identifers will be interpreted as the keyword await in a future version of Swift as part of SE-0296.
Runtime Performance and Code Size Improvements:
In Swift 5.4, protocol conformance checks at runtime are significantly faster, thanks to a faster hash table implementation for caching previous lookup results. In particular, this speeds up common runtime as? and as! casting operations.
Further, consecutive array modifications now avoid redundant uniqueness checks.
Finally, there are a variety of performance improvements:
String interpolations are more aggressively constant-folded
Fewer retain/release calls, especially for inout function arguments and within loops
Generic metadata in the Standard Library is now specialized at compile time, reducing dirty memory usage and improving performance
Swift Package Manager Updates:
The Swift Package Manager has several important updates in Swift 5.4:
Swift packages that specify a 5.4 tools version can now explicitly declare targets as executable, which allows the use of the @main keyword in package code (SE-0294)
Swift Package Manager is now supported on Windows!
Swift Package Manager caches package dependencies on a per-user basis, which reduces the amount of network traffic and increases performance of dependency resolution for subsequent uses of the same package
Automatic test discovery is now the default on all platforms, removing the need in LinuxMain.swift (which has been deprecated)
Multiple improvements to dependencies resolution infrastructure including in manifest loading and caching, leading to improved performance of dependency resolution
Improved diagnostics infrastructure and error messages, leading to more actionable error messages for dependency resolutions issues and beyond
Windows Platform Support:
Support for Swift on Windows has progressed in several important ways:
Swift Package Manager now works on Windows
The WinSDK module has been extended, covering a greater portion of the Windows developer SDK. This allows more of the APIs to be easily used for Windows applications without having to manually construct libraries to bridge the C interfaces to Swift
Improvements to the installer should make using the toolchain with external tools easier by reducing the flags needed by default on Windows
Developer Experience Improvements:
Build Performance:
The Swift compiler is much better at tracking dependencies between files, resulting in a significant reduction in the number of files compiled for many kinds of changes during incremental builds
Dependencies on member variables and functions of structs, enums, classes, and protocols are now tracked individually by the Swift compiler. This finer granularity speeds and shrinks rebuilds after changes to these entities
Incremental builds produce deterministic products in many more cases
Code Completion:
Code completion’s performance is now much faster within large function bodies. In one example within the swift-package-manager repository, code completion time for self. in Swift 5.4 is now 4 times faster (20ms → 5ms) than Swift 5.3, for repeated invocations in that file.
Code completion is also now more reliable in expressions that contain errors, and in expressions that are ambiguous without additional context.
Type Checker:
Swift 5.4 improves type checking performance for “linked” expressions such as a + b + (2 * c).
In addition, the type checker has improved performance for nested array literals that contain other literal expressions.
The type checker now has improved diagnostics for result builders, including invalid statements (e.g. invalid return statement), referencing invalid declarations, and pattern matching errors.
Debugging:
When debugging Swift code on Apple platforms, variables with resilient types (including Foundation value types such as URL, URLComponents, Notification, IndexPath, Decimal, Data, Date, Global, Measurement, and UUID) are displayed in the Xcode variable view and the frame variable / v command again.

New in Swift 5.3 (Sep 17, 2020)

Language and Standard Library:
New Features and Refinements:
Swift 5.3 brings many language refinements that improve the ergonomics of writing Swift code. These updates can help you be a more productive Swift programmer by reducing boilerplate and redundant code, and enabling more functionality to be defined in libraries that you may use.
Swift 5.3 implements the following proposals from the Swift Evolution process:
SE-0263 - Add a String Initializer with Access to Uninitialized Storage
SE-0266 - Synthesized Comparable conformance for enum types
SE-0267 - where clauses on contextually generic declarations
SE-0268 - Refine didSet Semantics
SE-0269 - Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur
SE-0276 - Multi-Pattern Catch Clauses
SE-0277 - Float16
SE-0279 - Multiple Trailing Closures
SE-0280 - Enum cases as protocol witnesses
SE-0281 - @main: Type-Based Program Entry Points
SE-0282 - Clarify the Swift memory consistency model ⚛︎
SE-0285 - Ease the transition to concise magic file strings
SE-0286 - Forward-scan matching for trailing closures
Many of these features were proposed and implemented by active community members: Kelvin Ma, Anthony Latsis, Suyash Srijan, Frederick Kellison-Linn and Owen Voorhees. Thank you for your contributions!
Swift 5.3 also includes fixes for several commonly-reported compiler limitations:
SR-75 - Unapplied references to protocol requirements are now supported
SR-7083 - lazy properties can define didSet and willSet accessors
SR-8814 - Generic classes can use default implementations of protocol requirements when conforming to protocols with associated types
Runtime Performance Improvements:
Swift 5.3 significantly improves both binary code size and runtime memory usage. Measurements of these improvements have yielded exciting results across various projects:
Starting with Swift 4, the Swift team at Apple has been measuring the binary code size of a Swift rewrite of a UIKit application (written in Objective-C) that ships with iOS. In Swift 4, the code size was about 2.3x the size of the Objective-C version. In Swift 5.3, the code size is under 1.5x the size of the Objective-C version.
In MovieSwiftUI, an excellent open-source SwiftUI app by Thomas Ricouard, the application logic code size is reduced by over 40% compared to Swift 5.1.
In a test app that creates an array of 400 model objects, the heap memory due to runtime overhead has been reduced to use less than 1/3 of the heap memory used in Swift 5.1.
These measurements were reported in the ‘What’s New in Swift’ talk at WWDC 2020.
Binary size improvements will vary by patterns of use. The biggest improvement is in projects that declare a large number of types, through reduction in the size of “value functions” – the invisible functions that the compiler generates to create, copy, and destroy value types. This is especially beneficial to SwiftUI apps.
Additionally, Swift applications now have lower heap memory overhead at runtime. The Swift runtime caches less information on startup to track things like protocol conformances, due to improvements in the runtime that made this caching less necessary. An application written in Swift should now use less heap memory than an otherwise-identical program written in Objective-C.
Developer Experience:
Indentation Improvements while Editing Code:
The automatic indentation implementation in SourceKit was overhauled in this release, fixing ~50 feedback reports in the process. In particular, the automatic indentation of the following cases are much improved in this release:
Chained method calls involving closures
Call arguments, parameters, and collection elements that span multiple lines, and
Multi-line if, guard and while conditions
Code Completion:
Swift 5.3 further improves code completion performance and quality:
Repeated code completion invocations inside function bodies are now up to 15 times faster compared to Swift 5.2. This was achieved by reusing some of the computation done for previous completions in the same file. These speedups will be visible in both Xcode and users of SourceKit-LSP.
Callable values of user-defined nominal types (SE-0253) are now supported in Swift code completion. Code completion shows the calling signature after a base expression followed by an opening parenthesis
Build Time Improvements:
Swift 5.3 incorporates a new strategy for how the compiler handles declarations in your Swift code. These changes bring several concrete improvements:
Faster incremental build times by avoiding duplicated compiler work across source files, and more accurately identifying code that has not changed from the previous build
Better correctness, by fixing multiple cases where the behavior of the compiler was sensitive to declaration order or nesting
Faster compilation of code that uses types with a large number of properties and functions that are imported from another library.
These improvements were achieved by expanding the adoption of a new centralized framework in the compiler that records fine-grained dependency information, caches the results of expensive computation that may need to be repeated, and automatically detects dependency cycles within your Swift code.
Compiler Diagnostics:
Swift 5.3 builds upon the diagnostics improvements in Swift 5.2 to further enhance the quality and precision of error messages, especially in SwiftUI code. More specifically, the transition to the New Diagnostics Architecture is now complete in Swift 5.3!
Many of the diagnostics improvements in 5.3 involve complex generic code where a generic argument has a failed requirement, such as a missing conformance.
Debugging:
Swift 5.3 supports better error messages for runtime failures. When debug info is available, the debugger will now display the reason for traps in the standard library instead of just showing an opaque invalid instruction crash.
LLDB is now more robust when debugging binaries that were compiled on a different machine:
SDK paths from the build machine are automatically recognized and remapped to local paths.
Source and include paths can optionally be remapped with .dSYM path remapping dictionaries.
Ecosystem:
Swift Package Manager:
Resources (SE-0271):
Packages can now contain resources such as images and other data files needed at runtime. Resources are scoped by target, and are processed and embedded into client apps when the package is built. Resources can be accessed from source code using Foundation’s Bundle API.
Resources that are specific to Apple platforms (such as asset catalogs, storyboards, and CoreData models) can only be built in Xcode, but generic resources are supported on all platforms. New API in the package manifest provides control over which source files to treat as resources.
Localization (SE-0278):
Packages can now contain localizable content such as .strings files and localized variants of resources. Localizable content can be added to a package using .lproj directories, and can be accessed using Foundation APIs.
Binary Dependencies (SE-0272):
Packages can now vend prebuilt libraries distributed as XCFrameworks, allowing dependencies on libraries that can’t be distributed as source code. This feature is currently only available when building for Apple platforms. New API in the package manifest lets XCFrameworks be referenced as binary targets.
Conditional Target Dependencies (SE-0273):
A package target’s dependencies can now be declared as conditional, which can be used to limit dependencies by platform. This provides more flexibility to describe complex target dependencies that support multiple platforms.
Note that conditions based on build configuration were also a part of the Swift evolution proposal, but are yet to be implemented, and are therefore not part of Swift 5.3.

New in Swift 5.2 (Mar 25, 2020)

This release focuses on improving the developer experience:
Improved compiler diagnostics (errors and warnings) and code completion
Increased reliability in debugging
Improved handling of dependencies in the Swift Package Manager
Tooling improvements with LSP and SwiftSyntax
… and much more. Further, a few additions to the language have been added that provide new capabilities for building expressive APIs. This blog post takes a quick tour of the main changes.
Language Updates:
Swift 5.2 implements the following language proposals from the Swift Evolution process:
SE-0249 Key Path Expressions as Functions
SE-0253 Callable values of user-defined nominal types
To experience these changes, explore a playground put together by Paul Hudson. John Sundell has also written an article, “Exploring Swift 5.2’s new functional features”, that illustrates the expressive capabilities of these new features.
Improved Compiler Diagnostics:
We have drastically improved the quality and precision of error messages in the Swift compiler.
Previously, the compiler attempted to guess the exact location of an error by breaking up an expression to search for failures in each subexpression separately. This worked well in cases where it is possible to narrow down the location of an error to a single subexpression without using any information about its parent expression. However, there were numerous kinds of programming mistakes that this strategy could not accurately identify.
The compiler leaves “breadcrumbs” when it encounters failures while inferring types in an expression, recording every specific failure along the way. These breadcrumbs allow the compiler to produce precise diagnostics, often with actionable fixes, that lead the developer toward correct code. Below are a few examples of improved error messages.
Code Completion Improvements:
Faster completion by eliminating unnecessary type checking. For large files it can speed-up code completion by 1.2x to 1.6x, compared to Xcode 11.3.1, depending on the completion position.
Now can supply names of implicit members for incomplete dictionary literals and incomplete ternary expressions.
Easier to read types when they appear in the results. Using opaque result types (e.g. some View) when possible and preserving typealiases. Stopped printing parent types if not necessary.
Improved Build Algorithms:
The Swift compiler supports two modes of operation:
Whole Module (typically used for Release builds)
Incremental (typically used for Debug builds)
The two modes have tradeoffs in compilation speed and amount of code optimization performed. Incremental builds are great during development where not every file in the project needs to be recompiled, and maximum optimization is not critical. Whole Module Optimization gives the compiler a more complete view of the entire code base and therefore a greater ability to optimize.
In an Incremental mode build, the work of rebuilding a module is split among multiple compilation tasks that run in parallel. For every source file that is rebuilt, there is exactly one associated compilation task responsible for type checking and generating code for the declarations in that source file.
Since Swift declarations (such as functions, properties, types, etc.) can reference each other across source files, a compilation task will sometimes be required to type check declarations in other source files. This cross-file referencing of declarations can decrease efficiency of an Incremental mode build because it can duplicate type-checking work across compilation tasks.
In contrast, Whole Module compilation works by processing all the code in a module in one compilation task. While there is no duplication of type checking work across compilation tasks, there is no parallelism when compiling the code in a module. Whole Module compilation, however, gives the compiler more visibility in one go over the code in a module and thus enables more code optimizations.
The build time advantage of Incremental over Whole Module compilation diminishes with the amount of duplicated work each compilation task performs. If this duplicated work is too high, it can be the case that Incremental mode does more work than Whole Module compilation. As long as the overhead does not exceed the number of processor cores, the Incremental mode build will still be faster overall, but reducing this overhead is key to improving build times.
Making Incremental Builds more Efficient:
In order to minimize the wasted work done by Incremental mode builds, the Swift 5.2 compiler — notably the type checker — leverages a new centralized logic for caching, lazy evaluation, and dependency tracking between requests, where a request is a self-contained unit of computation. This logic is now used by the compiler to more efficiently resolve declarations and their references to one another.
Prior to Swift 5.2, when a declaration was referenced in another source file, the type checker would explicitly perform an operation on this declaration, called validation. Validation made use of mutable state and was rather coarse-grained, attempting to pre-compute any number of properties of the declaration that might be needed later during code generation. This eager, pre-computation of information could often be unnecessary and wasteful.
In Swift 5.2, the internal representation of declarations in the compiler is immutable, and the code generation phase of the compiler is able to trigger lazy evaluation of requests, the result of which are cached. Since requests are more fine-grained than the old validation step, this improves performance by avoiding wasted work. It also improves correctness, fixing a significant number of correctness issues where the type checker did not anticipate needing to validate something that was later required for code generation.
Additional Improvements:
In addition to improved Incremental mode builds, the Swift 5.2 compiler includes a number of performance optimizations to foundational components such as the work the compiler does to resolve a named symbol to its declaration (i.e., name lookup). We expect that these improvements will improve build times for both Whole Module and Incremental mode builds. Since these changes reduce the algorithmic (big-O) complexity of various algorithms inside name lookup, they should particularly help on larger projects with many source files.
Debugger Improvements:
Across all platforms where Swift debugging is supported, LLDB is now more resilient in reconstructing type information for Swift programs from debug information. This resilience enables the debugger to use more information about Swift types.
In particular LLDB can now also import C and Objective-C types from DWARF debug information instead of compiling the Clang module from source code. This behavior can be controlled by the symbols.use-swift-dwarfimporter LLDB setting. By default this setting is enabled as a fallback path when the traditional Clang module import fails.
Example: Xcode variable view and expression evaluator:
To see these improvements in action, one can look at the variable view in Xcode or the LLDB expression evaluator. To power these debugging workflows, LLDB needs to import all Swift modules that are visible in the current debugging context (e.g., file, function, etc.). While Swift modules have a wealth of information about types, Swift modules often cannot be used just on their own without depending on separate modules files produced by Clang (the C/C++/Objective-C compiler) that are used for Swift code interoperating with C and Objective-C. Since LLDB has a global view of the entire program and all of its dynamic libraries with all their dependencies, importing Clang modules can sometimes fail. One common failure scenario is when the search paths from different dynamic libraries are in conflict.
Swift Package ManagerL
Swift Package Manager in Swift 5.2 includes the following new enhancements:
Remote Swift packages with tools version 5.2 and above no longer resolve package dependencies that are only used in their test targets, improving performance and reducing the chance of dependency version conflicts.
Swift Package Manager uses a new strategy to resolve package dependencies that significantly improves the quality of error messages and performance in complex package graphs.
These changes were a result of discussion and review as part of the Swift Evolution process: SE-0226 Package Manager Target Based Dependency Resolution
SwiftSyntax Updates:
The syntax node hierarchy in SwiftSyntax’s API has been optimized by replacing protocols with structs. Consequently, tree visitation, especially when rewriting with SyntaxRewriter, is now faster. This has resulted in improved performance during tree visitation and especially when rewriting the tree using SyntaxRewriter.
Language Server Protocol Updates:
Xcode 11.4 and the corresponding Command Line Tools package include the Swift 5.2 release of SourceKit-LSP language server for Swift and C-based languages.
To find the sourcekit-lsp server executable on macOS while Xcode 11.4 is the active Xcode:
# Run the server.
xcrun sourcekit-lsp
# Get the full path to the server.
xcrun --find sourcekit-lsp
SourceKit-LSP now includes support for the following LSP features:
FixIts: Swift errors, warnings and notes that include FixIts are now supported using Code Actions from the Language Server Protocol.
Local Refactoring: Swift local refactorings such as extract-to-method are now supported using the “Refactoring” Code Action kind.
SourceKit-LSP also has a number of improvements for supporting C/C++/Objective-C code. In particular, when determining compiler arguments for processing header files SourceKit-LSP now uses the index to lookup their main file for improved accuracy of results.
There are also some notable improvements for projects using JSON compilation databases (e.g. CMake projects):
Loading time of the compilation database was sped up by up to 10x
Indexing while building data is now supported by scraping the compilation database for the index store path arguments

New in Swift 5.1 (Sep 23, 2019)

New in Swift 5.0 (Mar 26, 2019)

New in Swift 4.2 (Sep 18, 2018)

New in Swift 4.1 (Mar 30, 2018)

New in Swift 4.1 Build 2017-11-01-a Dev (Nov 2, 2017)

New in Swift 3.1 (Mar 28, 2017)

New in Swift 3.1 Build 2017-01-22-a Dev (Jan 24, 2017)

New in Swift 3.0 2016-05-31-a Preview 1 (May 31, 2016)

SE-0081 "Move 'where' clause to end of declaration" is implemented, allowing you to write 'where' clauses after the signature for a declaration, but before its body.
SE-0071: "Allow (most) keywords in member references" is implemented. This allows the use of members after a dot without backticks, e.g. "foo.default".
SE-0057: Objective-C lightweight generic classes are now imported as generic types in Swift.
SE-0055: The types UnsafePointer, UnsafeMutablePointer, AutoreleasingUnsafeMutablePointer, OpaquePointer, Selector, and Zone (formerly NSZone) now represent non-nullable pointers, i.e. pointers that are never nil. A nullable pointer is now represented using Optional, e.g. UnsafePointer? For types imported from C, non-object pointers (such as int *) now have their nullability taken into account.
SE-0046 Function parameters now have consistent labelling across all function parameters. With this update the first parameter declarations will now match the existing behavior of the second and later parameters. This change makes the language simpler.
SE-0037 Comments are now treated as whitespace when determining whether an operator is prefix, postfix, or binary.
SE-0053 let is no longer accepted as a parameter attribute for functions. The compiler provides a fixit to remove it from the function declaration.
SE-0003 var is no longer accepted as a parameter attribute for functions. The compiler provides a fixit to create a shadow copy in the function body.
SE-0043 landed, adding the ability to declare variables in multiple patterns in cases. Renamification landed, so the Clang importer imports ObjC symbols substantially differently. Someone should expand on this point.
SE-0040 landed, changing attributes from using = in parameters lists to using :, aligning with function call syntax.
SE-0034 has renamed the #line directive (which resets the logical source location for diagnostics and debug information) to #sourceLocation.
SE-0064 The Objective-C selectors for the getter or setter of a property can now be referenced with #selector.
SE-0062: A key-path can now be formed with #keyPath.

New in Swift 2016-02-03a Snapshot (Mar 25, 2016)

New in Swift 2.2 (Jan 26, 2016)

Associated types in protocols can now be specified with a new 'associatedtype' declaration, to replace the use of 'typealias': protocol P { associatedtype Ty }. The typealias keyword is still allowed (but deprecated and produces a warning) in Swift 2.2. This warning will become an error in Swift 3.
Curried function syntax has been deprecated, and is slated to be removed in Swift 3.
The ++ and -- operators have been deprecated, and are slated to be removed in Swift 3.0. As a replacement, please use "x += 1" on integer or floating point types, and "x = x.successor()" on Index types.
The operator identifier lexer grammar has been revised to simplify the rules for operators that start with a dot ("."). The new rule is that an operator that starts with a dot may contain other dots in it, but operators that start with some other character may not contain dots. This eliminates a special case for the ..< operator, folding it into a simple and consistent rule.
The "C-style for loop", which is spelled for init; comparison; increment {} has been deprecated and is slated for removal in Swift 3.0. See SE-0007 for more information.
Three new doc comment fields, namely - keyword:, - recommended: and - recommendedover:, allow Swift users to cooperate with code completion engine to deliver more effective code completion results. The - keyword: field specifies concepts that are not fully manifested in declaration names. - recommended: indicates other declarations are preferred to the one decorated; to the contrary, - recommendedover: indicates the decorated declaration is preferred to those declarations whose names are specified.
Designated class initializers declared as failable or throwing may now return nil or throw an error, respectively, before the object has been fully initialized.
All slice types now have removeFirst() and removeLast() methods.
ArraySlice.removeFirst() now preserves element indices.
Global anyGenerator() functions have been changed into initializers on AnyGenerator, making the API more intuitive and idiomatic. They have been deprecated in Swift 2.2, and will be removed in Swift 3.
Closures appearing inside generic types and generic methods can now be converted to C function pointers as long as no generic type parameters are referenced in the closure's argument list or body. A conversion of a closure that references generic type parameters now produces a diagnostic instead of crashing. (rdar://problem/22204968)
Anonymously-typed members of C structs and unions can now be accessed from Swift. For example, given the following struct 'Pie', the 'crust' and 'filling' members are now imported. Since Swift does not support anonymous structs, these fields are imported as properties named crust and filling having nested types named Pie.__Unnamed_crust and Pie.__Unnamed_filling. (rdar://problem/21683348)
Argument labels and parameter names can now be any keyword except var, let, or inout.
Tuples (up to arity 6) whose elements are all Comparable or Equatable now implement the full set of comparison/equality operators. The comparison operators are defined in terms of lexicographical order. See SE-0015 for more information.
The @objc(SomeName) attribute is now supported on enums and enum cases to rename the generated Objective-C declaration. (rdar://problem/21930334)
When referencing a function or initializer, one can provide the complete name, including argument labels.
There is a new build configuration function, #if swift(>=x.y), which tests if the current Swift language version is at least x.y. This allows you to conditionally compile code for multiple language versions in the same file, even with different syntax, by deactivating parsing in inactive code blocks.