# RichTextKit bridges AppKit and UIKit, and its author may not keep it going

> RichTextKit is a MIT licensed Swift and SwiftUI library for viewing and editing rich text across Apple platforms, built by wrapping UITextView and NSTextView behind one context object. The decisive fact is in the README: with iOS and macOS 26 able to edit attributed strings in a TextEditor, the author says the library will most likely not be updated in its current direction.

**danielsaidi/RichTextKit** — View and edit rich text in SwiftUI.

- Repository: https://github.com/danielsaidi/RichTextKit
- Website: https://danielsaidi.com
- Stars: 1,274 · Forks: 163
- Language: Swift
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/danielsaidi-richtextkit

## One API over UITextView and NSTextView

RichTextKit is a library that lets you view and edit rich text in Swift and SwiftUI, on all major Apple platforms. The architecture is stated in one sentence and it decides everything else.

The RichTextEditor supports text styles such as bold, italic and underline, fonts, font sizes, colors, text alignments, image attachments and more, and it is powered by a RichTextView that bridges UITextView and NSTextView, adding platform-agnostic APIs that make the two views behave more alike. That is the entire trick: the two native text views on iOS and macOS have drifted apart over the years, and this library hides the difference behind a single SwiftUI surface.

The second half of the library is the read-only case. If you only want to display rich text content, RichTextViewer is a SwiftUI view that wraps the editor and applies a read-only configuration to it. Reusing the editor rather than writing a second rendering path is a sensible way to keep the two consistent, and it means the viewer inherits whatever the editor supports.

The package is MIT licensed, the badge in the README states Swift 5.9, and the platform badge is SwiftUI. The repository also carries the usual supporting files for a Swift package, with Sources/, Tests/, a Demo/ application and its Xcode project, scripts/, Package.swift, Package.resolved, a .swiftformat configuration, a .swiftlint.yml configuration, RELEASE_NOTES.md and Resources/.

## The context object is the API you actually touch

The editor takes a text binding and a RichTextContext, and the context is where the real interface lives. The editor uses a RichTextCoordinator to sync changes between the editor, the context and the platform specific view. You use the context to change font, colors and alignment, and you observe context changes to update the interface.

That three way sync is the part worth understanding. A SwiftUI text editor is a view over a native view, and a naive implementation loses cursor position, selection or undo history when state changes underneath it. The coordinator exists to keep the three representations agreeing, and the context is the SwiftUI-facing half of that arrangement.

The usage example shows how the pieces fit together, including the mechanism for exposing the context to the surrounding interface:

```swift
struct MyView: View {

    @State
    private var text = NSAttributedString(string: "Type here...")
    
    @StateObject
    var context = RichTextContext()

    var body: some View {
        RichTextEditor(text: $text, context: context) {
            // You can customize the native text view here
        }
        .focusedValue(\.richTextContext, context)
    }
}
```

The focusedValue call is the interesting line. It publishes the context into the SwiftUI focus system, which is how a toolbar or an inspector elsewhere in the hierarchy can reach the same context and change the font or the color of the current selection. The text is a plain NSAttributedString binding, so the model of the document is Foundation's attributed string and not a proprietary document type, which means it can be persisted with ordinary archiving or serialisation.

The viewer is the same idea in one line:

```swift
struct MyView: View {

    private var text = NSAttributedString(...)

    var body: some View {
        RichTextViewer(text: text)
    }
}
```

Beyond the editor itself, the library provides UI components, keyboard shortcuts and menu commands that can be used in a rich text editor, which is the part that saves a developer from rebuilding a formatting menu for every app.

## The author says the library may not be updated further

The most important paragraph in the README is a warning, and it is written by the library's author rather than inferred.

The repository was created a few years ago, when SwiftUI had limited support for rich text. Since then SwiftUI has received more support for attributed strings, and with the new iOS and macOS 26 releases it is now possible to edit attributed strings with a TextEditor. That, the README says, brings into question how much value the repository will bring over time, and that it will most likely not be updated in its current direction, since most of the complexities of integrating between SwiftUI and UIKit or AppKit will not be needed.

The author goes further. He says the library will most probably still be relevant for performing operations on the attributed string, and perhaps for providing control panels, and that regardless, things will be different, so he is not yet sure whether he will keep the library alive after the WWDC 25 announcements. He invites people to reach out to discuss it.

For an adopter this is a maintenance signal, not a technical one. The library works, the API is documented, the demo application is in the repository, and the code is MIT licensed, so you can fork and maintain it. What you cannot assume is that a new SwiftUI release will arrive with matching features.

The dates are consistent with that picture. The last push was on 2026-06-05, and the published releases are 1.2 from April 2025, the 1.2-b.1 beta from the same month, and 1.1.2 from January 2025. The repository is not archived, but the author has said it will most likely not be updated in its current direction, and the release line has not moved since 2025.

## The alternative is a native TextEditor, and the trade is old OS support

The comparison to make is not with another library but with the platform. On iOS and macOS 26, a TextEditor can edit attributed strings, so the baseline for a rich text field is now the system component, with no dependency, no bridging and no coordinator.

The difference in approach is that the native path gives you the system's own editing behaviour, its own selection handling and its own undo, and it costs nothing to maintain. The library path gives you a rich text editor that works across older operating system versions, a RichTextView whose platform differences are smoothed over, image attachment support, and the components, keyboard shortcuts and menu commands needed to build a formatting toolbar. If your app still supports systems released before the current one, the library covers cases the system editor does not, and if you only target the newest systems and need a simple formatted text area, the library is machinery you do not need.

There is a third option that sits between the two, and it is the one the author himself points at. The attributed string operations and the control panels may remain useful regardless of what the editor does, so a project could use the native TextEditor for editing and borrow the library's parts for commands, or port those parts into its own code.

The licensing makes all three options open. MIT means you can take the code, change it and ship it inside a closed application, and a fork is a legitimate way to take ownership of a library whose author is uncertain about its future.

## Installation is a package URL and a demo to copy from

Installation is through the Swift Package Manager, and the README gives the repository URL to add:

```bash
https://github.com/danielsaidi/RichTextKit.git
```

There is no dependency to install for the toolchain beyond that, and the package targets Swift 5.9 and SwiftUI. The README points to the online documentation for a getting started guide with more articles and code examples, and the documentation is hosted on GitHub Pages under the danielsaidi.github.io domain.

The fastest way to understand the intended usage is the demo application, which the README says lets you explore the library on iOS and macOS and can be opened and run directly from the Demo directory in the repository. That is a small but meaningful advantage of a library with an app next to it: you can see the editor wired to a context and a toolbar, and copy the structure rather than infer it.

For a reader building their first integration, the order of work follows from the API. Bind an NSAttributedString into the editor, hold a RichTextContext, publish it with focusedValue so a toolbar can reach it, add the components and commands for the formatting you want, and use RichTextViewer where the content is read only. The documented behaviour of the text styles, fonts, sizes, colors, alignments and image attachments is the feature list to check against your requirements.

## Sponsorship, tooling and a repository organised for maintenance

The project asks for sponsorship, with a sponsor link and a note that every contribution, no matter the size, makes a difference in keeping the tools free and actively developed. The author also lists his other open source tools and gives a website, an email address and social accounts for questions or contributions. This is a single maintainer project, and the README communicates that directly.

The repository layout reflects a package that is set up for ongoing work rather than a one off publication. Sources/ holds the library, Tests/ the test targets, Demo/ the sample application with its Xcode project and its own test target, and scripts/ the support scripts. The tooling configuration is in the tree as well, with a .swiftformat file and a .swiftlint.yml, so the formatting and lint rules the project expects are declared rather than left to each contributor's editor. Package.resolved is committed, which pins the dependency versions for a reproducible build, and RELEASE_NOTES.md is where a release's changes are recorded.

For an adopter, that combination is what decides whether a fork is cheap. A library with a test suite, a demo app, a lint configuration and release notes can be picked up and continued by a different team at a reasonable cost, and the MIT licence means nothing has to be negotiated to do it.

## Conclusion

RichTextKit still fits a team that has to support deployment targets older than iOS and macOS 26, that needs a rich text editor with a toolbar, and that is prepared to own the library, since the author explicitly invites people to reach out and says he is not sure whether he will keep it alive. It does not fit a new project starting today with the latest SDKs, where a TextEditor and a little attributed string work will do. Verify first the minimum OS versions the package declares and whether your app still needs a bridge between the two native text views, and read the RELEASE_NOTES.md file and the repository's last push, on 2026-06-05, before you plan a maintenance schedule around someone else's dependency.

## FAQ

### What does RichTextKit do?

It is a Swift and SwiftUI library for viewing and editing rich text on all major Apple platforms, powered by a RichTextView that bridges UITextView and NSTextView and adds platform-agnostic APIs, with RichTextEditor for editing and RichTextViewer for read only display.

### How do I install RichTextKit?

Through the Swift Package Manager, by adding the package at https://github.com/danielsaidi/RichTextKit.git. The README states Swift 5.9 and SwiftUI as the platform requirements.

### Will RichTextKit be kept up to date?

The author says in the README that it will most likely not be updated in its current direction, since SwiftUI and the new iOS and macOS 26 releases reduce the need for the SwiftUI and UIKit integration, and that he is not yet sure whether he will keep the library alive after the WWDC 25 announcements.

### What are RichTextContext and RichTextCoordinator for?

The context is the object you use to change font, colors and alignment and to observe changes, and the coordinator syncs changes between the editor, the context and the platform specific view. The context is published with focusedValue so a toolbar elsewhere in the hierarchy can reach it.

### What licence is RichTextKit under?

The MIT licence, with the LICENSE file in the repository and the licence also stated in the README. The Demo app, the test targets and the lint and format configuration are all included in the repository.

## Sources

- [danielsaidi/RichTextKit on GitHub](https://github.com/danielsaidi/RichTextKit)
- [License: MIT](https://github.com/danielsaidi/RichTextKit/blob/main/LICENSE)
- [Project website](https://danielsaidi.com)
- [README](https://github.com/danielsaidi/RichTextKit/blob/main/README.md)
- [Releases](https://github.com/danielsaidi/RichTextKit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/danielsaidi-richtextkit