Aztec puts visual HTML editing into a UITextView

A text view that speaks HTML

Aztec is a Swift library that provides a UITextView subclass with HTML visual editing capabilities. That single sentence is the whole design.

The subclassing is the interesting choice. A text view is what iOS apps already use for editable text, so the editor inherits the system text behaviours, selection handling, input methods and accessibility support that ship with the platform, and it renders rich content rather than showing markup to the user.

The readme splits the offer into two libraries with different audiences. Aztec itself is for an app that interacts with raw HTML content. WordPressEditor is a plugin that makes Aztec work with WordPress content, for an app that deals with WordPress HTML content. Both are published from this repository, with separate podspecs, WordPress-Aztec-iOS.podspec and WordPress-Editor-iOS.podspec, and both are referenced from the same Swift package.

The target audience is therefore an iOS developer whose content pipeline is HTML, and who wants the editor to look native rather than being a web view with a rich text editor bolted on. That is the case the project fits, and it is worth being clear that Aztec is a component, not an application.

Three distribution routes, one repository

Both libraries are available through Carthage, CocoaPods and Swift Package Manager, and the repository carries the artefacts for all three. There are two podspecs at the top level, a Package.swift, a .swiftpm/ directory, and a Gemfile with a Gemfile.lock for the Ruby tooling that supports the release process.

The choice between them is mostly about how much setup each one demands, and the Carthage route is the one with a step the others do not need. With Carthage, after adding the frameworks you have to add $(SDKROOT)/usr/include/libxml2/ to your target's Header Search Paths before linking Aztec.framework and importing the module. The libxml2 path is there because the library parses and serialises HTML through libxml2, so its headers have to be visible at build time.

Swift Package Manager is the newest route and the one with a version constraint. The readme notes that SPM support was added in version 1.20.0 and that tags prior to that will fail to resolve in SPM. If you are on an older tag and move to SPM, the resolution failure is expected rather than a mistake in your manifest.

There is also a fourth option for people who do not want a package manager at all: the readme says you can use the project repository URL directly through Xcode.

Carthage integration and the libxml2 step

The Carthage instructions start with the Cartfile. Both libraries are listed there, and the version is the only thing you have to change:

github "wordpress-mobile/AztecEditor-iOS" "1.0" # or the version number you want
github "wordpress-mobile/WordPressEditor-iOS" "1.0"

After Carthage builds the frameworks, the readme gives three steps. Open your project, go to Build Settings for your target and add $(SDKROOT)/usr/include/libxml2/ to the Header Search Paths. Then in Build Phases, under Link Binary With Libraries, add Aztec.framework. Finally, add import Aztec to your project's source.

The header search path is the step people miss, and its absence produces a build error in your own project rather than in the library, which makes it a confusing first failure. It is needed because the framework exposes headers that include libxml2 types, and the compiler has to find those declarations.

After that, the import is all you need from the build configuration side, and the type you import from is Aztec.

CocoaPods and Swift Package Manager manifests

With CocoaPods the Podfile is all you need:

pod "WordPress-Aztec-iOS", "1.0" # or the version number you want
pod "WordPress-Editor-iOS", "1.0"

The pod names differ from the repository names, which is worth noting if you are converting a Carthage setup, since the Carthage entries use the repository URLs and the pod entries use the pod names.

The Swift Package Manager manifest in the readme shows the two products you can depend on from the same package:

let package = Package(
    name: "YourPackage",
    products: [
        .library(name: "YourLibrary", targets: ["YourTarget"]),
    ],
    dependencies: [
        .package(url: "https://github.com/wordpress-mobile/AztecEditor-iOS", .upToNextMajor(from: "1.20.0")),
    ],

    targets: [
        .target(
            name: "YourTarget",
            dependencies: [
                .product(name: "Aztec", package: "AztecEditor-iOS"), // You can choose...
                .product(name: "WordPressEditor", package: "AztecEditor-iOS"), // which library you need.
            ]
        ),
    ]
)

The two products, Aztec and WordPressEditor, come from one package, so you can depend on the raw HTML editor alone or add the WordPress layer without pulling in a second dependency. The manifest also shows the version constraint style, upToNextMajor from 1.20.0, which matches the note that earlier tags do not resolve.

Creating the text view

Using the library is a matter of importing the module and constructing the view. The readme shows the Aztec.TextView initialiser:

import Aztec

// ...

let textView = Aztec.TextView(
    defaultFont: UIFont,
    defaultParagraphStyle: ParagraphStyle = ParagraphStyle.default,
    defaultMissingImage: UIImage) {

The three parameters are the interesting part. The default font and the default paragraph style define how text that carries no explicit formatting is rendered, which matters for an editor that has to display content written elsewhere, where the source HTML may not specify a font at all. The default missing image is the placeholder shown when the content references an image that cannot be loaded, which is a common case for a mobile editor where an attachment is still uploading or a remote image is unreachable.

The readme snippet stops there, which is a fair signal about the level of detail it provides. The repository does have a Documentation/ directory and a docs/ directory, and the Example/ directory contains a full application, so the constructor details beyond these three parameters are in the code and the sample app rather than in the readme.

The example app is the real documentation

The readme gives one line on running the example: open Aztec.xcworkspace from the root directory of Aztec, make sure the AztecExample target is selected, and press CMD + R to run it.

That is a workspace rather than a project file, which is the usual signal that the example has its own dependencies resolved at the workspace level. The Example/ directory in the repository listing backs that up, with Example/AztecExample.xcodeproj, Example/Example.xcworkspace, Example/Example/ and an Example/AztecUITests/ directory, so there is a UI test target alongside the app.

The presence of UI tests is worth a second look. For a component whose entire job is rendering and editing rich content, the interesting failures are visual and behavioural, a toolbar that does not appear, a selection that behaves oddly, a paste that loses formatting, and those are exactly the cases a UI test target exists to cover.

The repository also has a Tests/ directory at the top level for unit tests, a Scripts/ directory, a fastlane/ directory, and a .buildkite/ directory for continuous integration, along with a CircleCI badge in the readme. The Ruby tooling in the Gemfile and the .rubocop.yml file suggest the project runs some of its own linting through Ruby, which is common in repositories that publish their own releases from CI.

Requirements, licence and the gap between tags and commits

The requirements are stated briefly. Aztec needs iOS 11 and above, and Xcode 12 and above. That is a wide deployment target for a text component, and it is worth weighing against the SDK features your own app uses, since an editor component that supports iOS 11 also constrains the API surface you can rely on inside it.

The licence is the Mozilla Public License Version 2.0, and the readme states that AztecEditor-iOS and WordPress-Editor-iOS are open source projects covered by it, with the text in LICENSE.md. MPL 2.0 is a file level copyleft licence, so using the library in your own application does not oblige you to open source the application, but modifications to the library files themselves must be published.

On maintenance, the picture is mixed. The last release was 1.20.0 on 2025-02-05, with 1.19.11 from 2024-03-21 and 1.19.10 from 2024-02-24 before it. The last push was on 2026-10-19, so the code is being changed. The default branch is develop, which is the usual convention for a project where the released line is cut separately.

The practical consequence is that a Swift Package Manager dependency pinned with upToNextMajor from 1.20.0 will not pick up the recent work, while a checkout of the develop branch will. Whether to pin or track is a decision about how much churn you want in a dependency that renders user content.

Where Aztec is the wrong choice

The clearest wrong choice is plain text content. Aztec exists to render and edit HTML, and if your content is markdown or a simple rich text subset, a standard UITextView with a text attribute does the job without a component that parses XML.

The second wrong choice is a web view based editor that you already need for other reasons. If your application displays rendered HTML anyway, an editor implemented in the same web view shares that rendering context, and the arguments for a native component are weaker. Aztec's case is strongest when native appearance and native text behaviours matter more than sharing a rendering pipeline with the rest of the app.

There is also a cost to being inside the native text system. A UITextView subclass that renders HTML has to map document concepts such as paragraphs, lists and images onto text attributes and attachment views, and any content it cannot represent is where fidelity problems appear. The readme does not document which HTML features are supported, which is the first thing to check in your own content, and the Example app is the fastest way to see how your documents come out.

Finally, the release situation argues for pinning. If you need a component that the maintainers will keep publishing new versions of, the gap between the last tag in February 2025 and the recent commits is a factor to weigh.

Editorial conclusion

Adopt AztecEditor-iOS if you are building an iOS application that edits HTML and you want a native text view based editor rather than a web view, since Aztec is a UITextView subclass with visual HTML editing built in. Skip it if your content is plain text, if you are targeting only current iOS versions and want a modern package manager setup without the libxml2 header step, or if you need a release that is not from early 2025, because 1.20.0 is the newest tag. Before you start, run the AztecExample target from Aztec.xcworkspace, check that your build settings include the libxml2 header search path the Carthage instructions require, and confirm the XML parsing behaviour matches your own HTML content.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. wordpress-mobile/AztecEditor-iOS on GitHub