Why we built a native block editor

Select the end of a heading and the start of the paragraph below it. Type a replacement and keep writing. The note has blocks, but the edit can cross their boundaries.

We built Phrase's native block editor in Swift to own that continuity. On iPhone, it uses UIKit, CoreText, and UITextInput. The editable document is native, without a WebView.

We wanted a note to hold paragraphs, formulas, diagrams, images, and sources while still feeling like one place to write. Its structure should help organize the work without interrupting the passage being revised.

That choice put us in charge of the whole edit: the selected text, the affected blocks, and the cursor left behind.

A heading and a paragraph look different because they do different jobs. While revising, you may need to work across both.

In Phrase, you can select a continuous text range across blocks. Start partway through a heading, end partway through the next paragraph, and replace the selected words together. The text outside the selection stays.

We treat that as one writing action. Making each block editable on its own would leave the most interesting work at the boundaries: joining text, preserving formatting, and deciding where writing continues. Those decisions belong to the document.

The same principle applies when Enter splits a paragraph or Backspace joins it again. We want the structure to follow the edit you meant to make.

An explanation sometimes needs a formula. A plan might need a diagram. A saved source is easier to recognize when you can see its title and image.

Phrase supports math, Mermaid diagrams, images, and link previews alongside text. We render those blocks with native views, so they belong to the same page you are editing.

We also keep the kinds of selection distinct. Selecting words through two paragraphs means editing part of the text. Selecting an image or a whole checklist item means working with that block as a unit.

Our article on math, diagrams, and saved sources shows what these richer notes can look like.

Sometimes the words are right and the order is wrong.

We added a left swipe to select a block and a two-finger sweep to select a group. Dragging lets you change the order without cutting text and rebuilding the same blocks elsewhere.

The selection follows your fingers and remains when you lift them. You can see what you have chosen before acting on it. That feedback matters on a phone, where your hand is already covering part of the page.

The gesture article shows both selection gestures in the actual editor and explains how dragging changes the order.

CoreText gives us the typeset text. We use that layout to place the cursor and the selection around the words you see. On iOS, UITextInput connects the custom editor to the system's text input services.

A tap, a line break, and the next character have to agree about where writing happens. So does an input method that is still composing a phrase. When you type with Pinyin, for example, the text can change several times before you accept a candidate. We keep those provisional changes separate from committed edits.

These interactions connect the input system to the document. We keep that connection intact while you write, correct a candidate, or change your selection.

Owning an editor means maintaining the ordinary things people expect: text input, selection, undo, scrolling, and behavior across OS updates. We chose to take on that work because it gives us control over the interactions used throughout a writing session.

The useful payoff is a page that can grow richer without making small edits cumbersome. A few words can become a heading. A checklist can move. A calculation can sit beside its explanation. You can keep working in the same note.

For the technical route, read how Swift, CoreText, and native text input fit together. To try the interactions yourself, download Phrase for iPhone.