Migration Alamofire to 5.0 from 4.0

Lee young-jun
3 min readAug 20, 2023

--

I attempted to upgrade Alamofire within one of my apps, Talk-Translator.

The reason for this upgrade was because KakaoShare utilizes version 5 of Alamofire, whereas NaverPapago was still using version 4. It’s important to note that this specific instance of NaverPapago is not provided by Naver; rather, it is my custom Pod library designed to facilitate easy access to the Naver Papago API.

Alamofire

I incremented the Alamofire version in the Podspec of my custom library.

Nevertheless, my library couldn’t make use of version 5 of Alamofire due to an incompatibility with the Swift version. To address this, I visited the repository and identified the minimum Swift version required for the latest version of Alamofire.

Consequently, I raised the Swift version requirement to 5.5 in my library as well.

Although increasing version, got another error.

Alamofire.request Migration

I checked Migration Guide and noticed modifications.

Global Alamofire namespace usage, which was never really necessary, has been removed and replaced with a single AF reference to Session.default.

Notably, the previously unnecessary usage of the global Alamofire namespace has been eliminated and replaced with a singular AF .

AF.request(naverReq.urlRequest)

DataResponse migration

Subsequent to the substitution with AF, I encountered an additional error pertaining to the DataResponse type.

Generic type ‘DataResponse’ specialized with too few type parameters (got 1, but expected 2)

This error manifested within the code that utilizes the DataResponse type.

failureHandler: @escaping (F?, DataResponse<Data>) -> Void,

This occurred because DataResponse had undergone modifications.

To address this, I included Error as a generic parameter.

failureHandler: @escaping (F?, DataResponse<Data, Error>) -> Void,

‘DataRequest’ has no member ‘dataResponseSerializer’

While DataRequest originally possessed the dataResponseSerializer method, this is no longer the case.

return self.response(
queue: queue,
responseSerializer: DataRequest.dataResponseSerializer()

It had been moved, requiring the use of DataResponseSerializer.

return self.response(
queue: queue,
responseSerializer: DataResponseSerializer()

Cannot convert value of type ‘DataResponse<Data, AFError>’ to expected argument type ‘DataResponse<Data, any Error>’

The DataRequest.response method produces a response object with AFError as the error type. In response, I replaced the Error type in DataResponse

failureHandler: @escaping (F?, DataResponse<Data, Error>) -> Void,

with AFError.

failureHandler: @escaping (F?, DataResponse<Data, AFError>) -> Void,

Value of optional type ‘DispatchQueue?’ must be unwrapped to a value of type ‘DispatchQueue’

The DataRequest.response method no longer permits an optional queue. Consequently,

I made the queue parameter non-optional by replacing queue: DispatchQueue? with queue: DispatchQueue.

extension DataRequest {
...
public func responseObject<S, F>(success : S.Type, fail : F.Type,
queue: DispatchQueue,
...
return self.response(
queue: queue,
responseSerializer: DataResponseSerializer()

You can review all of my modifications in this particular commit.

References

--

--

No responses yet