Blog

Building a rich text editor for UIKit, AppKit and SwiftUI


In this article, we’ll look at how to build a rich text editor for UIKit, AppKit and SwiftUI. We’ll extend native types to extend the foundation support for rich text, create new types to bridge the various platforms and make sure that we have a basic, working foundation that we can expand in future posts.

This post was originally published as a guest article at the Cindori website. It’s published here as well, to serve as a baseline for future articles about rich text editing.

Background

Rich text editing on Apple’s platforms is pretty straightforward. Just create a UITextView in UIKit (iOS and tvOS) and an NSTextView in AppKit (macOS) and use NSAttributedString, and you’re good to go. The text views will automatically support different fonts, styles, alignments etc. as well as images and other kind of rich content with very little extra work.

Well, you could think that it’d be that easy, but unfortunately it’s not. Many basic tasks are actually pretty complicated. Adding multi-platform support to the mix makes things even worse, since UIKit and AppKit handle strings, attributes, attachments etc. differently.

Another complication is SwiftUI, where we have to find a way to embed and bridge the platform-specific views in a way that works on all platforms. We also need some way of letting SwiftUI affect the platform-specific views, and for the platform-specific views and their delegates to update SwiftUI as well.

All in all, this is pretty complicated, which is why I’m happy to announce that my wonderful client Oribi has given me permission to open-source a multi-platform rich text engine that I created for them as part of building a new version of their text editor Oribi Writer. The result is an open-source library that you’re able to use in your own projects. Many thanks to Oribi for this!

Designing for multi-platform

When building a multi-platform rich text engine that should also support SwiftUI, I was careful to design the foundation as platform-agnostic as possible. Designing for the unknown is often a vain task, but here I just designed it in a way that I thought would made sense for both UIKit and AppKit.

Long story short, I made a few assumptions that didn’t hold true when I started developing the macOS version. For instance, I assumed that UITextView and NSTextView scrolls in the same way (spoiler alert - they don’t). However, having a platform-agnostic foundation made such adjustments manageable.

One example is how to set up these views. We use UITextView in UIKit and NSTextView in AppKit, but since we’ll have to override some parts and add more rich text-specific functionality later, let’s create a new RichTextView view for both platforms:

#if os(iOS) || os(tvOS)
import UIKit

public class RichTextView: UITextView {}
#endif
#if os(macOS)
import AppKit

public class RichTextView: NSTextView {}
#endif

As you can see, we can only implement this view for macOS, iOS and tvOS, since UITextView is not available on watchOS.

Furthermore, the UITextView and NSTextView APIs differ quite a bit. For instance, to get and set the attributed string, UITextView has an attributedText property, while NSTextView has an attributedString() function to get the string and an optional textStorage property to change it.

To bridge these platform differences, we can extend the views with additional properties, to get the same APIs. I personally prefer to use protocols to enforce that this is done correctly. For these views, let’s add a RichTextViewRepresentable protocol:

public protocol RichTextViewRepresentable {

    var attributedString: NSAttributedString { get }
}

We can now make both text views implement this protocol by adding an attributedString to them:

#if os(iOS) || os(tvOS)
extension RichTextView: RichTextViewRepresentable {}

public extension RichTextView {
    
    var attributedString: NSAttributedString {
        get { attributedText ?? NSAttributedString(string: "") }
        set { attributedText = newValue }
    }
}
#endif
#if os(macOS)
extension RichTextView: RichTextViewRepresentable {}

public extension RichTextView {
    
    var attributedString: NSAttributedString {
        get { attributedString() }
        set { textStorage?.setAttributedString(newValue) }
    }
}
#endif

Using protocols to communicate bridging between platforms is a nice way to make our code cleaner in a controlled way and remove the need for #if checks within the library.

To design SwiftUI for multi-platform use, we can also add a ViewRepresentable typealias that makes platform-specific views in SwiftUI easier to define within the library.

#if os(iOS) || os(tvOS)
import UIKit

typealias ViewRepresentable = UIViewRepresentable
#endif

#if os(macOS)
import AppKit

typealias ViewRepresentable = NSViewRepresentable
#endif

This will make the SwiftUI rich text editor that we’ll create next cleaner, since it can now implement the ViewRepresentable protocol without having to care about the platform differences.

Creating a rich text editor for SwiftUI

To use these new text views in SwiftUI, we can create a RichTextEditor view that wraps either of the two views depending on which platform we’re on:

#if os(iOS) || os(macOS) || os(tvOS)
import SwiftUI

public struct RichTextEditor: ViewRepresentable {

    public init(text: Binding<NSAttributedString>) {
        self._attributedString = text
    }


    @Binding
    public var attributedString: NSAttributedString


    #if os(iOS) || os(tvOS)
    public let textView = RichTextView()

    public func makeUIView(context: Context) -> some UIView {
        textView.attributedString = attributedString
        return textView
    }

    public func updateUIView(_ view: UIViewType, context: Context) {}
    #endif

    #if os(macOS)
    public let scrollView = RichTextView.scrollableTextView()

    public var textView: RichTextView {
        scrollView.documentView as? RichTextView ?? RichTextView()
    }

    public func makeNSView(context: Context) -> some NSView {
        textView.attributedString = attributedString
        return scrollView
    }

    public func updateNSView(_ view: NSViewType, context: Context) {}
    #endif
}
#endif

To create a rich text editor, we have to provide it with an NSAttributedString binding. This could be any custom string or content that comes from e.g. a document in a document-based app. The editor will display the rich text that we provide it with, and will be able to edit it as well.

The code above shows one of my first AppKit learnings as I started porting the editor to macOS. As you can see, iOS and tvOS just use the RichTextView that we created earlier. I first tried doing the same for macOS, just to find that the editor didn’t scroll.

Turns out that in AppKit, you must create a scroll view from the text view type that you want to use, cast its documentView to get a text view, then use the scrollView to get the scrollable behavior that we get by default in iOS. We’ll need the text view later, so let’s also add a textView property.

We’re now ready to take the SwiftUI text editor for a test ride! If we create a SwiftUI test app with a rich text binding and add a TextEditor to its content view, you’ll find that you can provide the editor with any rich text and type in the editor to edit the text.

However, there’s something missing. If you edit text in the editor, then print the value of the text binding, or add a Text view that shows the text, you’ll notice that typing in the text field doesn’t update the text.

A screenshow of how changes are not synced from the text view back to the state binding

In the image above, I have typed in the text field, but the Text view still shows the original text. This is because we never write back any changes in the rich text editor to the text binding. Let’s fix that next.

Syncing changes

To listen for changes in the text editor and sync them back to the text binding, we need to implement text view delegation. However, since TextEditor is a struct, it can’t be used as the text view delegate.

We can solve this by adding a coordinator to the rich text editor and use it as delegate. Let’s create a RichTextCoordinator and use it to coordinate changes between SwiftUI and the underlying views.

#if os(iOS) || os(macOS) || os(tvOS)
import SwiftUI

open class RichTextCoordinator: NSObject {

    public init(
        text: Binding<NSAttributedString>,
        textView: RichTextView) {
        textView.attributedString = text.wrappedValue
        self.text = text
        self.textView = textView
        super.init()
        self.textView.delegate = self
    }

    public var text: Binding<NSAttributedString>

    public private(set) var textView: RichTextView
}
#endif

The coordinator is given a text binding and a RichTextView and will sync changes between both. We can also remove setting the attributedString in the editor, since the coordinator handles this for us.

To be able to set the coordinator as the text view delegate, we first have to make it implement both the UITextViewDelegate and the NSTextViewDelegate protocol.

#if os(iOS) || os(tvOS)
import UIKit

extension RichTextCoordinator: UITextViewDelegate {}

#elseif os(macOS)
import AppKit

extension RichTextCoordinator: NSTextViewDelegate {}
#endif

We can then set the coordinator as the text view delegate in the RichTextCoordinator initializer:

open class RichTextCoordinator: NSObject {

    public init(
        text: Binding<NSAttributedString>,
        textView: RichTextView) {
        textView.attributedString = text.wrappedValue
        self.text = text
        self.textView = textView
        super.init()
        textView.delegate = self // <-- New line!
    }

    ...
}

For the coordinator to actually do anything, we need to implement a few delegate functions. Before we do, let’s first add a way to sync the text binding with the text view:

private extension RichTextEditorCoordinator {

    func syncWithTextView() {
        syncTextWithTextView()
    }

    func syncTextWithTextView() {
        if text.wrappedValue == textView.attributedString { return }
        text.wrappedValue = textView.attributedString
    }
}

We can now setup the (so far limited) delegate handling to update the text binding when we type in the text view or changes its selection:

open class RichTextCoordinator: NSObject {

    ...

    #if canImport(UIKit)

    open func textViewDidChange(_ textView: UITextView) {
        syncWithTextView()
    }

    open func textViewDidChangeSelection(_ textView: UITextView) {
        syncWithTextView()
    }

    #endif

    #if canImport(AppKit)

    open func textDidChange(_ notification: Notification) {
        syncWithTextView()
    }

    open func textViewDidChangeSelection(_ notification: Notification) {
        syncWithTextView()
    }

    #endif
}

With this code, the coordinator will sync changes back to the text binding. Still, if we run the test app, the original text still doesn’t update. This is because we haven’t put the coordinator to use yet.

We can fix this by making the rich text editor setup a RichTextCoordinator in makeCoordinator:

public struct RichTextEditor: ViewRepresentable {

    ... 

    public func makeCoordinator() -> RichTextCoordinator {
        RichTextCoordinator(
            text: text,
            textView: textView)
    }
}

If we run the test app again, you’ll see that the text is now updated when we type in the rich text editor. This is because our coordinator listens for changes in the text field and updates the text binding for us.

However, tapping the button to change the text still doesn’t update the rich text editor. This is something we have to leave for later, since updating the editor is quite tricky, if we want things like the text position to behave correctly whenever the text changes.

Instead, let’s look at how to change text style and let us toggle bold, italic and underline for the current position or selection in our rich text editor.

Working with text styles

To support text styling, we have to find a way to get and set if the text is bold, italic, underlined etc. This isn’t as straightforward as you may think. Bold and italic are symbolic font traits, while underline is a text attribute, which means that we have to handle styles in different ways. UIKit and AppKit then adds even more differences to the mix, which complicates things further.

To get attribute information for the attributed string, we can use attributes(at:effectiveRange:). However, ranges and strings are a dangerous combo, since invalid ranges will cause the code to crash.

Therefore, let’s add a safeRange function to NSAtrributedString, to shield us from invalid ranges:

public extension NSAttributedString {
    
    func safeRange(for range: NSRange) -> NSRange {
        NSRange(
            location: max(0, min(length-1, range.location)),
            length: min(range.length, max(0, length - range.location)))
    }
}

We can now add NSAtrributedString extensions that get a single or all attributes at a certain range:

public extension NSAttributedString {

    func textAttribute<Value>(_ key: Key, at range: NSRange) -> Value? {
        textAttributes(at: range)[key] as? Value
    }

    func textAttributes(at range: NSRange) -> [Key: Any] {
        if length == 0 { return [:] }
        let range = safeRange(for: range)
        return attributes(at: range.location, effectiveRange: nil)
    }
}

To actually change attributes for a certain range, we can create another extension. Note that we need to extend NSMutableAttributedString instead of NSAttributedString:

public extension NSMutableAttributedString {

    func setTextAttribute(_ key: Key, to newValue: Any, at range: NSRange) {
        let range = safeRange(for: range)
        guard length > 0, range.location >= 0 else { return }
        beginEditing()
        enumerateAttribute(key, in: range, options: .init()) { value, range, _ in
            removeAttribute(key, range: range)
            addAttribute(key, value: newValue, range: range)
            fixAttributes(in: range)
        }
        endEditing()
    }
}

Phew, that’s a mouthful. Still, these extensions will now help us get and set text attributes like .font, .underlineStyle etc. and will make it easier to create a clean api.

Still, traits like bold and italic can’t be retrieved and set directly with attributes. Instead, we have to use fonts. Going through this would make the post very long, so let’s use the extensions above for now, although they are intended to be used internally in the library, rather than by developers. Let’s add more convenience utils later.

Changing text styles

If we were to use UIKit and AppKit, the TextView and its attributed string would already be able to get and set attributes, which means that we could for instance toggle underline, change font etc.

In SwiftUI, however, we have to find a way to observe the current state of the text view, like we did when we synced text view changes back to the text binding. However, we then had a text binding to sync with. For things like traits, attributes etc. we need to find a way to manage that state in an observable way.

We can solve this by introducing a new, observable class that we can use to keep track of the current state of the text view. Let’s call it RichTextContext.

public class RichTextContext: ObservableObject {

    public init() {}
}

Let’s then adjust the RichTextEditor and RichTextCoordinator to require such a context:

public struct RichTextEditor: ViewRepresentable {

    public init(
        text: Binding<NSAttributedString>,
        context: RichTextContext) {
        self.text = text
        self._richTextContext = ObservedObject(wrappedValue: context)
    }

    private var text: Binding<NSAttributedString>

    @ObservedObject
    private var richTextContext: RichTextContext

    ...
}
open class RichTextCoordinator: NSObject {

    public init(
        text: Binding<NSAttributedString>,
        textView: RichTextView,
        context: RichTextContext) {
        textView.attributedString = text.wrappedValue
        self.text = text
        self.textView = textView
        self.context = context
        super.init()
        self.textView.delegate = self
    }

    public var context: RichTextContext

    ...
}

We can now add observable information to the context, for instance if the text is underlined or not:

public class RichTextContext: ObservableObject {

    ...

    @Published
    public var isUnderlined = false

    ...
}

We can then use the same text view delegation as before to sync this information with the context when the text view’s text or position changes:

private extension RichTextCoordinator {

    func syncWithTextView() {
        syncContextWithTextView()
        syncTextWithTextView()
    }

    func syncContextWithTextView() {
        let string = textView.attributedString
        let attributes = string.textAttributes(at: textView.selectedRange)
        let isUnderlined = (attributes[.underlineStyle] as? Int) == 1
        context.isUnderlined = isUnderlined
    }

    ...
}

As you can see, the code is still rough even though we added a textAttributes(at:) function to the text view. This is why we should add more extensions later, to make these operations easier.

You can now add a @StateObject private var context = RichTextContext() to the test app and pass it into the RichTextEditor. When you move the text input cursor, the coordinator will sync the underline information with the context, which you can then use as you wish in SwiftUI.

However, we currently have no way to make the rich text underlined from SwiftUI. We have the required functionality, but no way to trigger it from SwiftUI. Since SwiftUI views are structs, we also have no view reference that a button could use. We have to find another way.

Turns out that we’ve actually just added a way to solve this - the context. If we could somehow observe context changes, we could fix so that just changing the context’s isUnderlined could tell something with access to the text view to act on that change. Turns out we have this thing as well - the coordinator.

The coordinator could use Combine to observe the context, then apply the correct changes directly to the native text view, which in turn would update the text binding.

Let’s first add a way for the coordinator to store context observables:

open class RichTextEditorCoordinator: NSObject, RichTextPresenter {
    
    ...
    
    public var cancellables = Set<AnyCancellable>()

    ...
}

Then let’s add a way for the coordinator to subscribe to context changes:

open class RichTextEditorCoordinator: NSObject, RichTextPresenter {
    
    public init(
        text: Binding<NSAttributedString>,
        textView: RichTextView,
        textContext: RichTextContext) {
        ...
        subscribeToContextChanges()
    }

    ...
}

private extension RichTextEditorCoordinator {
    
    func subscribeToContextChanges() {
        subscribeToIsUnderlined()
    }

    func subscribeToIsUnderlined() {
        richTextContext.$isUnderlined
            .sink(
                receiveCompletion: { _ in },
                receiveValue: { [weak self] in self?.setIsUnderlined(to: $0) })
            .store(in: &cancellables)
    }

    func setIsUnderlined(to newValue: Bool) {
        let string = textView.attributedString
        let attributes = string.textAttributes(at: textView.selectedRange)
        let isUnderlined = (attributes[.underlineStyle] as? Int) == 1
        if newValue == isUnderlined { return }
        let value = NSNumber(value: newValue)
        // How to set the text attribute??
    }
}

As you can see, we have to duplicate the isUnderlined logic from earlier. This is a clear indication (and the content for another post) that we should find a way to simplify this logic further.

However, let’s leave it like this for now, and instead discuss how we can set this new attribute. We can’t change the text view’s attributedString since it’s not mutable, so we have to find another way.

Turns out that UIKit has a non-optional textStorage, while NSKit has an optional property with the same name. Let’s use these to add a mutableAttributedString to the text views:

public protocol RichTextViewRepresentable {

    ...
    
    var mutableAttributedString: NSMutableAttributedString? { get }
}

// Then add this to both the UIKit and AppKit view
public extension RichTextView {

    var mutableAttributedString: NSMutableAttributedString? {
        textStorage
    }
}

We can now use the mutableAttributedString to set the underline style:

private extension RichTextEditorCoordinator {
    
    ...

    func setIsUnderlined(to newValue: Bool) {
        ...
        textView
            .mutableAttributedString
            .setCurrentTextAttribute(.underlineStyle, to: value)
    }
}

And with that, we’re done (for now)! The coordinator will write to the context whenever the text view’s text or position changes, and will observe and sync changes in the context with the text view.

Trying it out

We can now add a button to our test app and have it highlight when the rich text context indicates that the current text is underlined. We can also tap the button to toggle the underlined style:

Two iOS devices showing underline support

Two macOS windows showing underline support

There are still tons to do to make attribute and trait management easier, and we haven’t even started looking at more advanced features like image support. However, we now have a solid, multi-platform foundation that we can expand further.

Introducing RichTextKit

This post has highlighted some of the complicated APIs that we have to use when working with rich text, how much that behaves differently between platforms and how much that’s missing in SwiftUI. I’ve spent many hours wrestling strange edge cases, and have searched all over the web to find nuggets of useful information in 10+ years old Objective-C posts etc.

Since I have already implemented all the rich text functionality covered in this post and much more while working for a Swedish company called Oribi while developing a new version of their Oribi Writer rich text editor, we felt that it’s such a waste that all developers have to reinvent the same wheel and work around the same limitations every time a new rich text-based app is to be developed.

This is why I’m happy to announce that we’ll be making all the rich text functionality that we have already implemented available as an open-source library. The library is called RichTextKit and provides you with functionality to make working with rich text a lot easier in UIKit, AppKit and SwiftUI.

RichTextKit logo

RichTextKit is under development, but already provides the functionality featured in this post, as well as functionality to work with rich text, attributes, styles, traits etc. It even supports images and has a demo app that lets you try out many of its features. If you think rich text is an exciting topic, I’d love to get your eyes on it, to make rich text on Apple’s platforms much more fun than it is today.

Conclusion

Although UIKit and AppKit has a bunch of built-in support for rich text, a lot is missing. Also, some things work very differently in UIKit and AppKit, which makes multi-platform a hassle. Finally, SwiftUI requires a bit of tricky coordination between the various layers to get things to work.

I hope that this post has made some things clearer and that you found the examples interesting. You can find the source code in the RichTextKit library, which I will evolve over time.

Thanks for reading!

Discussion

I hope that you found this post interesting. I would love to hear your thoughts and feedback, so feel free to comment in the Disqus section below or in this tweet.