What’s New in Swift, Issue 2

Submitted by matt_eaton on Mon, 12/17/2018 - 08:53 PM

Tags

Swift

What’s new in Swift is a news feed that focuses on the latest articles, trends, and stories happening around the Swift ecosystem that I find interesting. All of the topics selected in this article have been cherry picked from either Github, Swift.org, or found the Swift Forums over the last few weeks and can range from topics covered in iOS, macOS, tvOS, watchOS, or in the Server Side community. This latest issue focuses on moving Swift NIO to Boring SSL, Alamofire 5 Beta, a unified Server Side Swift Logging API, and the SE-0235 - Result Tye Being added to the Standard Library.

RFC: Moving Swift NIO SSL to BoringSSL

An RFC was posted on the Swift Forums recently to move Swift NIO to BoringSSL. The reason being is that this that each version of Linux today running Swift-NIO supports a different version of libssl. Why this is painful is because most developers who are writing their code in development are doing it on macOS, which has different support than Linux for libssl. The solution discussed in this RFC is to vendor a copy of BoringSSL with Swift-NIO-SSL to provide a consistent TLS implementation across development and deployment to Linux. I think this is a great idea to stabilize development and deployment environments.

Alamofire 5 Beta 1: Better, Stronger, Faster!

One of my favorite Networking libraries for Swift, Alamofire, has put out a Swift 5 beta 1 release. This release includes improvements to the ResponseSerializer, SessionManager, and all of the Request types available in Alamofire (Modeled after the one going into the stdlib). This release also includes additions for Asynchronous request creation, HTTPHeaders type and convenience APIs, and support for Encodable parameter types with JSONParameterEncoder and URLEncodedFormParameterEncoder.

Swift Server Logging API

On December 15th Johannes Weiss posted a proposal went up on the Swift Forums to standardize a Server Logging API across all Swift on the Server applications. So, no matter if you are running Vapor, Perfect, or Kitura, you will have a standard logging avenue provided to you with an API called LogHandler that would be distributed as a Swift Module. Read more about this new logging API with the links below.

SE-0235 Add Result to the Standard Library

Swift and Objective-C APIs have existed for a long time now without a unified way to express errors in result type as an asynchronous callback. A proposal to change (SE-0235) that has been accepted with modifications in the Swift language. This proposal will aim to unify result types in completion handlers to make it easier for developers to reason about errors or data returning in an API completion handler. Specifically, I think this will be a great move forward for all of the URLSession APIs.

URLSession.shared.dataTask(with: url) { (result: Result<(URLResponse, Data), Error>) in // Type added for illustration purposes.
    switch result {
    case .value(let response):
        handleResponse(response.0, data: response.1)
    case .error(let error):
        handleError(error)
    }
}

Member for

3 years 9 months

Matt Eaton

Long time mobile team lead with a love for network engineering, security, IoT, oss, writing, wireless, and mobile. Avid runner and determined health nut living in the greater Chicagoland area.

Twitter

Github