Alamofire 5.0.0 RC 1 Released!

Related Projects Alamofire
1

I'm happy to announce that Alamofire 5 has finally hit release candidate status and is now API stable. Our work now is to fix any bugs the community finds as we update our Advanced Usage documentation and write a (very long) migration guide.

RC 1 Release Notes

Added

  • cancelAllRequests method on Session to cancel all in flight requests.
  • Ability to inject FileManager instance into UploadRequest.
  • DataPreprocessor protocol and implementations, allowing the preprocessing of data before serialization.
  • Internal URLRequest validation and error. GET requests with body data will now produce an error.
  • Generic Failure constraint to DataResponse and DownloadResponse, making them DataResponse<Success, Failure: Error> and DownloadResponse<Success, Failure: Error>.
  • Precondition to ensure Session can't be used with background URLSessionConfigurations. Alamofire will explicitly support such functionality at some point in the future.
  • SwiftFormat configuration and updated styling.
  • AFDataResponse<Success> and AFDownloadResponse<Success> typealiases to help deal with the doubly generic responses.

Updated

  • All internal Result usage to use the fully qualified type instead of AFResult.
  • DataRequest and DownloadRequest functional API, renaming flatMap to tryMap.
  • HTTPMethod to be a struct rather than an enum.
  • All errors produced by Alamofire to be AFError by default. All responses will now start with an AFError Failure type.
  • NetworkReachabilityManager to simplify and modernize its API.
  • Usage.md documentation to be fully up-to-date with Alamofire 5.
  • Bundle identifiers to include the platform name, fixing ITMS-90806.

Fixed

  • Thread-safety issue with serialization queue usage.

The biggest change between beta 7 and RC 1 is that Alamofire's *Response types are now doubly generic just like Result. This means that transforming responses can preserve error types. This also enables us to use AFError as the error type for all responses, and we've added the AFDataResponse and AFDownloadResponse types to help with that transition. Simply replacing previous uses of the response types with their AF counterparts should make this a seamless transition.

Please report any bugs you find to our GitHub, while any discussion of new APIs or feature requests should take place in this forum.

2 Likes