CocoaAsyncSocket: one class per protocol and four ways to add it

GCDAsyncSocket and GCDAsyncUdpSocket are the entire library

The feature list names exactly two classes, and both are described as native Objective-C and fully self-contained in one class. GCDAsyncSocket covers TCP/IP, GCDAsyncUdpSocket covers UDP/IP. The top level matches that shape: Source/, Tests/, Examples/, CocoaAsyncSocket.podspec, CocoaAsyncSocket.xcodeproj/, Package.swift, a Gemfile with a Gemfile.lock, a .travis.yml, LICENSE.txt and a .github/ directory. What you get is a transport with none of the layers that usually sit above one. The README lists no HTTP client, websocket or file transfer helper. If your feature needs a request line, a status code or a frame header, you write it, and every project that adopts this library writes it again.

Both classes own a dispatch_queue and your delegate queue runs beside it

Thread safety here is a stated design property rather than a hope. Each class runs entirely within its own GCD dispatch_queue and is described as completely thread-safe, and delegate methods are invoked asynchronously onto a dispatch_queue of your choosing. The README is explicit about what that arrangement buys, parallel operation of your socket code and your delegate or processing code. The practical consequence is that your delegate callbacks do not arrive on the main queue unless you put them there, so anything touching UIKit needs your own hop back, and the two halves of the library proceed at the same time instead of in lockstep. The README does not say which queue a delegate call lands on when you never supply one, so treat the default as something to confirm in your own code rather than an assumption.

TLS is one method call on the TCP class and has no entry on UDP

Secure your socket with ease using just a single method call is how the TCP class offers TLS, and the line adds that it is available for both client and server sockets. Now read the UDP class. Its entries are delegate support for errors, send completions, receive completions and disconnections, queued non-blocking send and receive with optional timeouts, IPv4 and IPv6, and the same GCD threading model. There is no encryption entry at all, so the two halves of the library are not symmetric in what they can secure, and datagram traffic is the case where you would want it most. The consequence for a reader is that protected UDP is not something this project claims to do, and a design that needs it must be built above the class or sourced elsewhere. The README does not say what happens to a TCP TLS socket after the peer closes either.

Carthage, CocoaPods and SwiftPM resolve to three different versions

The three managers do not agree on what version you receive. The CocoaPods snippet names the pod with no version constraint in it, and the newest tag on the repository is 7.6.5 from 2020-12-13. Carthage is told to follow a branch instead:

github "robbiehanson/CocoaAsyncSocket" "master"

Swift Package Manager is given a floor:

dependencies: [
    .package(url: "https://github.com/robbiehanson/CocoaAsyncSocket", from: "7.6.4")
]

The last recorded push to master is 2026-08-30. So one route hands you the newest tag, one hands you the branch tip, and one starts at 7.6.4 and moves forward from there. The consequence is that the same library can enter your build as several year old code or as current branch code depending on a single line you pasted, and when behaviour differs between your app and someone else's, you have no version story to tell.

use_frameworks! is a Podfile-wide switch the CocoaPods recipe leans on

CocoaPods is the shortest instruction in the file and it carries a condition inside a comment:

use_frameworks! # Add this if you are targeting iOS 8+ or using Swift
pod 'CocoaAsyncSocket'

Read that comment as a dependency on your project rather than on this library. use_frameworks! applies to the Podfile as a whole, so turning it on for a Swift target or an iOS 8 target changes how every other pod is linked as well. That is the cost of this route, and it is not a CocoaAsyncSocket setting you can scope to a single pod. If your project deliberately avoids dynamic frameworks, editing the Podfile to accommodate one socket library is a trade worth naming out loud before you make it. The alternatives on this screen are the Carthage and Swift Package Manager routes, which skip the Podfile edit and bring the version resolution difference along instead.

Carthage builds three frameworks and asks you to embed one by hand

The project is configured to build for iOS, tvOS and Mac, so a Carthage build produces all three variants and leaves them in separate directories: Carthage/Build/iOS/CocoaAsyncSocket.framework, Carthage/Build/tvOS/CocoaAsyncSocket.framework and Carthage/Build/Mac/CocoaAsyncSocket.framework. What follows is an instruction to select the correct framework or frameworks and drag it into your project. Nothing automates that step and nothing checks it. The cost of this route is that you own the variant choice and the upgrade path, because there is no version pin in the Cartfile line and a rebuild takes whatever master holds. A fourth option adds the source files directly, which the README permits while steering you toward a dependency manager.

Examples/GCD and Examples/RunLoop point at two integration models

The Examples/ directory holds two subdirectories, GCD and RunLoop, and that split is the clearest statement about how the library expects to be driven. The GCD set is named for the dispatch model the feature list describes. The other is named RunLoop. The README does not say which set to copy from, which one is kept current, or how their setup differs, so a new user reads both to work out which one fits. A Tests/ directory sits alongside them, and the repository carries a .travis.yml. All three release tags predate 2021, so read the example you intend to build on rather than assuming the first one you find is the current one.

The wiki and a Google Group stand in for the API manual

The README is a feature list. For everything that matters once you are inside the code it points elsewhere twice: it recommends the wiki to anyone new to networking, with the warning that sockets might not work exactly like you think they do, and it offers a Google Group mailing list for people who still have questions. That is an honest statement about where the answers live. Method signatures, delegate protocol methods, timeout values and the precise behaviour of a queued read have no description in this file, so a lookup that fails means a trip to the wiki or the group.

Editorial conclusion

Choose it if you are writing an Objective-C or Swift networking layer on Apple platforms and want raw TCP or UDP without touching low level sockets. Step back if you need an HTTP client, a websocket, or encrypted datagrams, since none of those appear in the feature lists. Before you commit, compare how the three install methods resolve versions, confirm the delegate queue you are handed, and read the wiki, because the README explains neither a default queue nor a minimum operating system beyond the iOS 8 mention in the Podfile comment.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. robbiehanson/CocoaAsyncSocket on GitHub