Our DNA is written in Swift

Rich Text Editing on iOS

For the past few days you’ve see me go on and on about this Open Source Project of mine. Sorry if this got a bit annoying to you but I am very passionate about bringing this functionality to a broad audience because I feel that UIWebView should not be used as much as it is. With the DTAttributedTextView from the GitHub project you can replace most of these and have way more control over the outcome.

Apple might finally add support for Rich Text Editing in iOS 5, coming Summer 2011. I suspect that the Pages app on the iPad might be a glorified test case for Apple for that. But even if that indeed comes to our Xcode, it will be end of 2011 that customers will have widely deployed iOS 5


Today I want to show you something completely different that is using the aforementioned project as a base and extends it to provide Rich Text Editing capability.

40 Required Protocol Methods

So I investigated a little bit and found that since 3.2 Apple is exposing the editing protocols to build our own text editing views.

UITextInput – the main editing protocol with about 40 methods in total that you need to implement

UIKeyInput – on this UITextInput is based, it has only 3 methods allowing you to add basic single key input to views

UITextInputTraits – several properties that allow to customize behavior like capitalization and autocorrection

An editing view must implement the above protocols, be able to becomeFirstResponder and have userInteraction enabled.

You have to implement your own UITextRange and UITextPosition subclasses because different editors might have different values symbolize a certain position or range in a document. The example given is that an HTML document might  have a position in the visible text as well as a position in the HTML code.

CoreText now Objective

To make it easier on myself I encapsulated CoreText in Objective-C, you find these classes prefixed DTCoreText in the Open Source project. I found it very effective to have both the HTML project as well as my editor project open side by side so that it does not matter where I am making modifications to the display classes. And also the HTML project is benefitting from utility methods that I am adding to DTCoreText.

In the HTML project demo there’s now a “Debug Frames” button that lets you toggle showing of all the individual layout elements that CoreText is using: frame, baseline, lines and glyph runs. Characters that have the same attributes make up a glyph run, they alternate in red and green shading.

Because you can add any kind of UIView to the DTAttributedContentView as a response to a glyph run you can also do something that you could not do with a web view before: add your own custom views, surrounded by HTML. No longer do you need javascript or Flash to achieve interactive rich text…. Think of the possibilities, you can now place an object tag in the HTML and then within your app replace this object tag with a fancy interactive view. Or something as simple as an SVG image rendered by another open source component, like SVGQuartzRenderer, SVGKit or CKSVG.

DTRichTextEditorView is a subclass of DTAttributedTextView adding all the required methods mentioned above. And then some. For example I also have a blinking cursor view.

Working so far are:

  • Cursor Movements
  • Positioning the cursor via tap
  • if you enter text it gets the same formatting as the text where it is inserted
  • if the cursor is scrolled offscreen then entering text scrolls it into the visible area

Still missing:

  • Autocorrection already works, but I am still wrestling with getting the rectangle for the selection. There might be a bug on the Retina iPhone simulator not taking into account the scale factor.
  • Selecting/Marking Ranges
  • Pasteboard Integration: Cut, Copy, Paste

I’ve recorded a video to show off some cool features from the Open Source project and also give a tech preview of DTRichTextEditorView. The demo is still missing some sort of format chooser, in the least some buttons to change font and make it bold or italic. But these are simple to add and I will do so once I tackled the harder problems.

In the end another interesting question will be how to get HTML back from an NSAttributedString. There are multiple options thinkable. Either you preserve the original HTML and have the editor edit both the NSAttributedString as well as an underlying HTML DOM. Or you generate HTML code from the NSAttributedString.

Does it blend?

It is my goal with this component to have it be super-easy to implement and allow to super-charge any app that has some sort of editing capability. The possibilities are limitless:

  • Apps to post to blogs or social media
  • HTML editors
  • Note taking apps to allow for highlighting sections and make words bold and italic
  • E-Mail apps that allow you to use stationary, signatures and rich text
  • Twitter clients which make links, usernames and hash tags not just clickable but interactive.

What are your ideas? Got any apps that could use a “Rich Upgrade?”

If you can think of any good use for this component then you have three options. You can be an early adopter and purchase this component at an early adopter BETA preview rate. If you cannot afford the cost for this, then I am open to suggestions for partnerships. You bring the app, I bring the component and we split the profits. Or if you are looking to do a free app then I might be open for supplying the component if the app has a large enough audience.

I am very interested to hear your feedback to this article and the tech demo video.

Categories: Parts


  1. Very cool. Are you planning on supporting UITextInputTraits, for example for enabling autocorrect?

  2. Oops, just noticed in the article that UITextInputTraits is implemented in your paid component.

  3. Great article. Thanks Oliver for the great information. It is awesome you share this knowledge.

  4. I might have misread, but did you mention the price you would ask for the component to purchase?

  5. It’s not set yet, but it will be several hundred Euros.

  6. I’m sure many developers, including myself, are interested in such a control. Do you have an expected timeframe for v1.0?

    Also, I know Omni Group open-sourced a lot of their framework classes, including their RTF editor found here:

    Can you talk a bit about how your design approach differs from their?

  7. Sounds interesting. I’d like to know when this is available.

  8. I can’t seem to find an email address on this page, I am interested in licensing this product please email me with contact information.


  9. The Big Email button is too hidden?

    Development will resume mid of June.