Fifteen modules are still unaudited, the deployment floor is iOS 8, and the last commit is April 2024

The newest release is from December 2020 and the last commit is April 2024

Three releases are on record. Version 4.0.0 is from June 2018, version 3.7.0 from February 2017, and version 4.1.0 from 2020-12-31. The default branch took its last commit on 2024-04-22. That gap between a six-year-old release and a two-year-old commit is the single most important fact for anyone considering adoption, and the page does not draw attention to it. What it does instead is describe a migration as unfinished: the notes for moving from 3.7 to 4.0 say the process is still not complete and ask for issues to help minimise future breaking changes, while listing one rename that would be a warning in 4.0 and removed in 4.1. The invitation to send pull requests is unqualified, so read it as a description of the project's policy rather than as a statement about how quickly changes land.

The deployment floor is iOS 8, macOS 10.9 and tvOS 9

The install section is a single line: the minimum deployment target is iOS 8.0, macOS 10.9 or tvOS 9.0. Those are floors set before most of the current platform generations existed, and they are a property of the framework rather than of your project and the README says nothing further about them. The CocoaPods and Carthage instructions follow under the Swift Support heading and are covered below.

Fifteen modules are still unaudited, and the readme names them

The migration work is framed as adding nullability annotations and generics to the Objective-C sources, and the page is precise about how far it got. Core, authentication, categories and utilities have been audited. Extensions have not, and the unaudited list is printed: blocking, ping, time, archiving, capabilities, multi-user chat, vcard-temp, privacy, last activity, remote procedure calls, the roster, a Google shared-status module, file transfer, the CoreData storage layer and a bandwidth monitor. Four entries carry a parenthetical saying their storage implementations are also unaudited, which is the more important half for anyone storing data. The page's own conclusion is the operative sentence: if you use one of these, its API may still contain breaking changes in a future release. That is a warning about the specific modules most applications would reach for first.

Swift support is a one-way door by design

The framework now accepts Swift contributions, and the constraints are stated as rules rather than preferences. Swift code must live in one designated folder. No existing or future Objective-C code may depend on anything in it, in either direction of time. And every public API written in Swift must be usable from Objective-C, which in practice means marking it for Objective-C interop. The result is a strict layering: the Objective-C core cannot know the Swift layer exists, and the Swift layer is a set of additions rather than a rewrite. The migration section shows the reasoning behind that design, since the nullability annotations that make Swift pleasant are also what breaks pure Swift projects at compile time. The cost is that the Swift layer has to work within Objective-C's constraints, and the benefit is that the core stays usable from both languages.

Three package managers, and one of them needs a manual import

Distribution goes through three systems and the page treats them as equals. CocoaPods is called the easiest route, with one line for the Objective-C portion alone and a second line, behind a flag that switches the integration to dynamic frameworks, for the Swift additions:

pod 'XMPPFramework'

After installing, you are told to open the workspace rather than the project, which is the step people miss. Carthage is a repository line in a dependency file, a build command, and then a manual drag of the built framework into your project. The catch is stated immediately after: if you want the Swift features you have to drag a second framework in as well, and you must write the import for it by hand in your headers. The tree also contains a Swift package manifest and a .swiftpm/ directory.

Running the tests needs both dependency managers at once

The contributing section is the longest part of the page and it is dominated by the mechanics of getting a test run working. You need both dependency managers installed, and the order matters: check out the Carthage dependencies at the root of the repository, then run a bundle install followed by the CocoaPods install in each of the two platform test folders. New test files do not go where you would expect. They are created in one shared folder and then added, separately, to three different projects or workspaces, one of them in the Carthage test folder and two of them in the platform folders. The framework ships a mock stream class that the page recommends for testing, with worked examples to copy. For Swift work there is a further requirement that the unit tests pass for both integrations, which is why a Swift example and a dedicated test target are pointed at by name.

Security problems go to an email address with a published key

One paragraph in the contributing section is the most responsible thing on the page. If you find a security problem, you are asked not to open a public issue, and instead to email one of the maintainers directly. The address is given, along with a link to a GPG key file so the message can be verified. That is a disclosure policy stated where a contributor will read it, with a specific destination rather than a vague request, and it sits in contrast to everything around it, which is ordinary public issue and pull request workflow. Two smaller signals sit alongside it. Larger features are asked to start as an issue for community input, which is the same courtesy applied to design. And the list of places help is wanted is specific: nullability annotations and generics across the framework, more test coverage, and modernising the older example projects.

The abstract promises parallelism from an old iPhone to a twelve-core Mac Pro

The opening describes what the framework is: a core implementation of the XMPP standard, the tools needed to read and write XML, and a set of extension specifications built on a modular architecture where you plug in the code you need. The performance claim is that it is massively parallel and thread-safe, structured with dispatch queues, and performs well whether it runs on an old iPhone or a twelve-core machine, with a parenthetical promise that it will not block the main thread at all. No measurement accompanies any of that, and no machine is named beyond the two endpoints, so the claim is best read as an architectural intention rather than a benchmark.

Editorial conclusion

XMPPFramework makes sense if you are building an Apple-platform client and want the protocol layer plus a set of extension modules rather than a full application, and the modular layout means you can adopt one XEP at a time. Two things to know before you start. The deployment floor is iOS 8.0 and macOS 10.9, and Swift support is deliberately one-way, with Swift code isolated in a folder that the Objective-C side may not depend on. And the last commit on the default branch is dated 2024-04-22, with the newest release from December 2020 and the migration notes describing work as still incomplete, so read the unaudited module list before you build on any of it.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes