Using Alamofire from Objective-C

Alamofire is a popular networking framework written in swift, to be used in swift. As we dont leave in a perfect world, not all projects we are working with are 100% swift 😁. Therefore, there might be cases where one would want to write the new code using swift, but still need to maintain the Objective-c parts.

The project I am currently working on, we integrated alamofire and also made it accessible from Objective-c. I will walk you through the process and the transformations that were necessary to expose the swift API to Objective-c.

Step 1: Redefine the enumerations

The reason why you cannot access some part in Objective-c (even after annotating objects or methods as @objc or having them as public) is that some constructs cannot be translated to Objective-c. For example, an enumeration over String in swift cannot be translated. Therefore, the code generator will just ignore any method that has a parameter of that type. This means, the generated header will not contain any declaration for your method, making it unavailable from Objective-c.

This is the case with the alamofire implementation too. Some of the enums that are being used as types for some of the parameters are over String.

The first step to be able to use the networking framework is to write some wrappers on top of these enumerations that can be translated to Objective-c. These would basically look like this:

The code above wrapps the Method and the ParameterEncoding enums. It also includes the code to translate from the newly defined enums to the alamofire ones.

Step 2: Trigger the request in your manager

The alamofire methods return a Request object which does not inherit from NSObject and is, therefore, not visible in Objective-c.

I handled this problem the following way: in the AlamofireWrapper class, declare a method which takes as parameters:

  • the parameters you would need to create an alamofire Request (method, URLString, parameters, enconding, headers)
  • success and failure blocks that will be executed when the request is finished. Since in Objective-c, it is not possible to trigger the alamofire request, we have to trigger it in the wrapper and then send the response back to the calling object.

This will basically look something like the following:

Step 3: Parse the response

The request is being triggered inside the wrapper and returns a response object which of Response<AnyObject, NSError> type, which is again not visible in Objective-c. Therefore, we need to get the necessary information from this object and send it back through the success/failure blocks.

The parsing would look something like this:

Step 4: Make the successful call from Objc and rejoyce 🎊���🎊

With these 3 first steps, we can now make a request from Objective-c, that uses alamofire as the networking library.

Getting into more detail for more complex requirements

The steps described above, they help you make a simple JSON request using alamofire as the networking framework, regardless if your project uses swift or Objective-c.

However, in more complex projects, you might need more than just simple JSON requests, like download files, upload them, download with progress. For being able to wrap these requests too, you need a bit more work in your AlamofireWrapper class.

Lets start with uploading multipart forms.

Alamofire MultipartFormData

To upload forms with alamofire, you need to provide a block that constructs the formData (basically, just like in AFNetworking). However, this block is declared as:

multipartFormData: MultipartFormData -> Void

Yet again, MultipartFormData is not an NSObject subclass, so this will not be visible in Objective-C. This is how I found a workaround this:

First, I implemented an object that can contain all the data necessary to append a new MultipartFormData part. This would look something like this:

Using now the BodyPart object, we can write a wrapper on top of the upload method.

In this way, we can upload forms with alamofire from both Objective-c and swift. Again 🎊

Some final observations

As I have experienced, a great part of the functionality can be wrapped so that it is usable also from Objective-c.

However, you might have noticed, if you compared the enumerations I defined with the ones declared in alamofire that some very specific functionality can’t really be translated. For example, the last two values in the ParameterEncoding enum.

public enum ParameterEncoding {
case URL
case URLEncodedInURL
case JSON
case PropertyList(NSPropertyListFormat, NSPropertyListWriteOptions)
case Custom((URLRequestConvertible, [String: AnyObject]?) -> (NSMutableURLRequest, NSError?))

One more advantage you have for wrapping the alamofire calls, besides being able to use it from Objective-c, is that you can handle the parsing of the response only once.

You might have noticed, from the code snippets above, that figuring out if there was an error, if the JSON is or not invalid, if the request returned a success HTTP code but no JSON (which should be a success case), is not that straighforward. Therefore, the wrapper around the alamofire code, provides a single point where all this parsing happens.

One more thing..

This article can be seen as a guide to making swift code visible in Objective-C with a focus or a starting point on alamofire. I consider the most important aspect that it should bring forward, is a more clear view on when is swift code not visible in Objective-c and how, with rather small changes and without giving up the expressivity of the language, code can be easily accessible from both languages.

You can find the complete implementation on GitHub here:

Thanks for taking the time to read this article and I hope you find it useful in your daily work :)

Don’t hesitate to get in touch if you have questions or any suggestions.