MQTT iOS Frameworks Comparison

If you are new to the MQTT or just want to refresh your knowledge, please read my overview of the technology first.

The first step to build a stable and reliable iOS application with use of the MQTT protocol is to take some time to determine all use cases and possible scenarios. Based on that the expected specification can be created for the second step - choosing the right broker. The implementation of it on the server is not a task for iOS developer, but it’s important to know what are its functionalities and limitations. Only after that, the proper framework for iOS can be chosen.

There are lots of the MQTT clients available. I had an experience with two of them: CocoaMQTT and MQTT-Client-Framework. However, there is also a third very tempting option, which is Moscapsule. The purpose of this blog post is to compare all three of them especially in terms of differences.

Glossary

• LWT - Last Will and Testament. A feature of the MQTT which allows the broker to publish a message (testament) on a certain topic after the client which set it up previously disconnects ungracefully, for example by killing the application or losing the network connection.
  
  
• SSL/TLS - although the encryption may be crucial for some applications, it’s better to not encrypt the whole communication which may lead to significant increase of messages sizes. However, the support for it may be useful in terms of authenticating the client with encrypted username and password.
  
  
• QoS - Quality of Service, 0 - at most once, 1 - at least once, 2 - exactly once. It can be set per message or topic.
  
  
• Retained messages - messages stored on the broker side and sent to the clients subscribing to the certain topic after the original message was published.
  
  
• Throttling - in case of large numbers of messages being received at once, a nice-to-have feature is a possibility to set the limit. Implemented throttling can use the TCP backpressure mechanisms to prevent the broker from overwhelming the application and crashing it.
  
  
• Offline Buffering - when a client is offline for quite some time, the amount of the undelivered messages stored on the broker side may be huge. It is good for the certain MQTT client to have a possibility to buffer all those messages to receive and process them all at once.
  
  
• Bulk subscriptions - an ability to pack more than one topic a client wishes to subscribe to into the single subscribe message. Significantly reduces the time of subscribing to a large number of topics, for example to an online status of all of the contacts in phone’s contacts book.
  
  
• Clean session - a session established between a client and a broker, which does not keep the subscriptions after disconnecting. A client needs to re-subscribe for all topics at every connection.
  
  
• Persistent session - in opposite to a clean session, the information about subscriptions are kept on the broker side. After reconnecting a client does not need to resubscribe, it will get all of the retained messages it missed between connections.

Comparison

CocoaMQTT

CocoaMQTT is the MQTT client written in Swift 3.1 by Feng Lee, CrazyWisdom, and Alex Yu. It’s been built for iOS, macOS, and tvOS with Xcode 8.3.1. It can be installed with the use of CocoaPods or Carthage.

Pros:

• Easy to integrate and use.
• Written in Swift.
• An example application for chatting.
• Frequent releases (although the last one is from 25 July).
• iOS, macOS and tvOS support.

Cons:

• Supported brokers are not listed.
• Does not support bulk subscriptions.
• Some users reported memory leaks.
• Lack of support for 3.1 version of the MQTT protocol.
• Does not use all possible Swift features, for example, closures.
• Lack of documentation.
• Unit tests cover only small portion of the code.

MQTT-Client-Framework

Initially built by Christoph Krey MQTT-Client Framework is a powerful tool for most of the possible scenarios. It can be integrated via CocoaPods, Carthage, used as a dynamic library or finally built from the source code. Written in Objective-C is the most mature solution from the three frameworks.

Pros:

• Complete MQTT client framework with support for both MQTT 3.1 and 3.1.1 protocol standards.
• Supports bulk subscriptions and throttling.
• Frequent releases, lots of contributors and a small number of unresolved issues.
• Works with most of the brokers.
• Extensive documentation.
• iOS, macOS and tvOS support.
• Thoroughly tested with use of unit tests.
• Three brokers are available in the repository.
• Example application written in Objective-C.

Cons:

• Written in Objective-C, needs a bridging header for Swift applications.
• It’s a really powerful framework, not every application will need all of its functionalities.

Moscapsule

MQTT client written purely in Swift implemented as a wrapper of Mosquitto library. It covers almost all the features of Mosquitto 1.4.8. Created by a developer hiding under the name of tonary. It can be integrated via CocoaPods or built from the source code.

Pros:

• Pure Swift with use of the language features like closures.
• Designed as a wrapper of Mosquitto which makes it the best choice for this broker.
• Tested with unit tests.
• Swift 4 compatible (but the framework needs to be built from the source, the latest release supports only Swift 2).

Cons:

• The latest release is dated 26 September 2015.
• Lots of unresolved issues on GitHub.
• Supports only Mosquitto broker.
• Lack of support for macOS and tvOS.

Summary

The decision which client is the best needs to be done per project and should not be limited only to three frameworks described above. However, some conclusions can be made.

If the project is relatively simple, uses MQTT 3.1.1 protocol and there is no need for bulk subscriptions - CocoaMQTT should be more than enough.

If the project is big, uses MQTT extensively, the final functionalities are not yet determined or the application needs to be stable and reliable at cost of having a big dependency - choose MQTT-Client-Framework.

If the project uses Mosquitto - consider Moscapsule.

Photo by Steven Lelham on Unsplash