Lexical iOS is a TextKit editor still in pre-release

An extensible text editor layered over TextKit

Lexical iOS is a text editor and renderer written in Swift, built on top of TextKit, and it deliberately mirrors the philosophy and API of Lexical JavaScript. The point of the project is not to invent an editor but to port a model that web developers already know: the editor state is structured, plugins extend behaviour, and the framework owns the rendering pipeline rather than the host app. The description frames it as an extensible text editor framework that integrates the APIs and philosophies from Lexical Web with a Swift API. That framing matters for evaluation. A team that has already built with Lexical Web gets a familiar vocabulary of nodes, commands and updates. A team with no Lexical experience gets a structured editor model with fewer conventional iOS editor libraries to compare against, and the README says the full documentation lives in a separate documentation site.

LexicalView, EditorConfig and the update closure

The programmatic surface is small enough to describe in a sentence. For editable text you instantiate a LexicalView, and you configure it with plugins and a theme through an EditorConfig passed into the view's initialiser. To work with the data inside that view you need the Editor, and you call editor.update {}, with the Lexical API available inside that closure. That single update closure is the whole mutation model, which is the part a reviewer should look at first: every change to document state, whether it comes from a command, a plugin or the keyboard, passes through it. Themes are passed as configuration rather than set afterwards, so an app assembles its editor the same way it assembles other views. The README points at the documentation site for anything beyond this short tour, so treat the summary above as the shape of the API, not the complete contract.

Adding the package: core is packaged, plugins are not

Installation is a Swift Package Manager dependency, and the repository ships a package file that is sufficient to build Lexical core:

The catch is stated plainly in the README: some plugins included in this repository do not yet have package files, because Meta uses a different build system internally. The reason given is friendly, an easy pull request for anyone who wants to contribute. The practical effect is that core is consumable today while any plugin you depend on may require you to vendor the source or add the package file yourself. There is no podspec and no CocoaPods path described. The playground app in the Playground/ directory contains the code for a rich text toolbar, and the README is careful to say it is not a reusable toolbar you can drop straight into your projects, but a starting point for customising.

Platform floor of iOS 13, with the playground sitting higher

Lexical iOS targets iOS 13 and above, which is a generous floor for a framework that renders rich content. The exception is the playground app, which requires at least iOS 14 because of UIKit features such as UIMenu. That distinction is easy to miss and easy to get wrong: reading the sample code and copying its menu based toolbar into a product that still supports iOS 13 devices will not compile there. It also tells you something about the sample's age and the API style it demonstrates. The repository layout backs this up, with a Lexical/ directory for the framework, a Plugins/ directory for the extensions, LexicalTests/ for the test suite, Playground/ for the sample and docs/ for documentation resources and the changelog that lives under the Lexical documentation bundle.

Where the framework already earns its keep at Meta

The strongest argument for the project is production evidence rather than feature lists. The README states that Lexical iOS is used in multiple apps at Meta, including rendering feed posts that contain inline images in Workplace iOS. Inline images inside feed posts is exactly the kind of task where a plain text view is not enough and where a web engine ported to native has to earn its complexity. It also implies that the editor is exercised against real content, real layout and real performance constraints rather than a demo dataset. The counterpart to that evidence is the same README's warning that Lexical iOS is in pre-release with no guarantee of support, which is a deliberate signal to outside adopters. A framework shipping inside several Meta apps and a framework offering no support commitment are both true at once, and any adoption decision has to hold both facts in view.

Tests exist, end-to-end tests do not

Lexical has a suite of unit tests in XCTest format, which can be run from within Xcode. The README adds that there are currently no end-to-end tests. That boundary tells you where the risk sits. Unit tests can cover node construction, update semantics and plugin behaviour in isolation, but the hard parts of a text editor framework are compositional: keyboard handling, selection, TextKit layout and scrolling interacting with each other. None of that is exercised by a unit suite. The repository also carries a Package.resolved and a .swiftpm/ directory, and the workflow for changes is described in CONTRIBUTING.md, with a Discord server offered as the place for questions. For a team with its own UI test infrastructure, that gap is less alarming. For a team that expects the framework to come with regression coverage for gestures and layout, it is a real cost.

A three year gap between the release tags and the last push

The release history and the commit history say different things. The tagged versions are 0.1 from 2023-07-05 and 0.2 from 2023-11-15, while the last push was on 2026-10-19. So work continues in the repository, but there has been no new tag in the interval and the project still describes itself as pre-release with no guarantee of support. For an adopter this has a direct consequence: the version you depend on is decided by commit reference rather than by a published release, and the changelog entry you need for your own upgrade notes comes from the Lexical iOS Changelog inside the documentation bundle. Whether the recent pushes are stability work, new platform support or refactoring is not something the README states, so the honest summary is that the project is alive without a release cadence to rely on. Version pinning to a tag is still possible, but you then pin to a 2023 snapshot of a framework whose own authors decline to guarantee support.

Where TextKit-based frameworks fit against other iOS editors

The alternative is to build the editing surface on UIKit and TextKit directly, or on a conventional iOS text view with attributed string handling, and to add only the features your app needs. That approach buys you full control of layout and a familiar model, and it costs you every rich text feature you have to implement and maintain. Lexical iOS takes the opposite position: adopt the Lexical Web model, the plugin system and the TextKit based renderer, and get that feature set for the price of accepting a pre-release status and a Meta specific build story for some plugins. The interesting middle case is a hybrid, where a product needs a handful of inline images in a feed, which the framework already handles in production at Meta, and nothing else, in which case pulling in an entire editor framework for one surface is hard to justify. Decide by feature surface, not by the reputation of the editor model.

Editorial conclusion

Lexical iOS fits a team shipping a rich text surface inside an iOS app that needs the Lexical Web editing model and can absorb pre-release risk, for instance a feed with inline images of the kind the framework renders in Workplace iOS. It does not fit a product that needs a stable API, a documented support commitment or end-to-end tests, because the project offers none of those and its release tags stop at 0.2.0 in November 2023. Before committing, read the Lexical iOS Changelog for the differences between versions, check whether the plugins you need ship a package file, and confirm that targeting iOS 13 covers the devices you must support.

Frequently asked questions

Official sources

1. facebook/lexical-ios on GitHub
2. Issues
3. License: MIT
4. README
5. Releases