Making small edits fast in a 10,000-block document

In our 10,000-block Mac editor test, typing took a median of 1.01 milliseconds of editor work. Steady scrolling took 0.28 milliseconds per update.

We care about those numbers because long notes grow through small edits. You scroll to a passage, change a sentence, and add another thought. The document may be enormous; the next action is still local.

Phrase for Mac is now on the Mac App Store. Its native AppKit editor is built to keep those everyday actions responsive as a note grows, with shared Swift and CoreText foundations underneath.

Only a small part of a long document fits in the window. We keep views around that visible area and change the group as you scroll. The editor does not need a live view for every block to keep the whole document available.

We apply the same discipline to layout. Content on screen or under active editing needs an accurate layout now. We can defer some work for distant content and refine it as that content becomes relevant.

An edit gives us another useful boundary. Change one word and most of the note remains the same. We reuse layout that is still valid and update the content affected by the edit.

A local change can move later content without invalidating its text measurements. Keeping those costs separate is central to our block editor architecture.

We tested the Mac editor in a Release build on Apple Silicon with a generated document starting at 10,000 blocks. We measured each operation on the main thread and took the median of its samples.

For scrolling, we moved through the document in repeated steps after its layout had been refined. For typing, we inserted characters into an existing text block. The resize test changed the available width on each sample, and the Enter test repeatedly split text into a new paragraph.

These tests use generated content in an in-memory editing fixture. They measure the editor's main-thread work, excluding storage, synchronization, and the remaining rendering pipeline. We did not retain the exact Mac model or OS version for this run, so use these results to understand the cost of the operations within our test, rather than as a device comparison.

The split costs more than an insertion because it changes the document's structure as well as its text. Measuring both keeps that difference visible. A typing improvement alone would not tell us whether Enter had become faster.

A width change can alter line breaks throughout a document. Paragraphs become taller or shorter, moving the content below them.

We prioritize the visible passage during that work. We also preserve reading position in relation to the content, because the same vertical scroll offset can point to a different sentence after reflow.

That is what makes resize performance worth measuring in a long note: the amount of work can grow far beyond the few paragraphs visible in the window. We need to keep the current passage steady while its layout changes.

A display refreshing at 120Hz has about 8.3 milliseconds between refreshes. Our editor work consumes part of that time; preparing and rendering the visible frame takes more. Apple's guide to animation hitches explains those stages.

We use this budget to guide the work we can control. The table reports operation times, not a measured display frame rate.

For Phrase, the point of a 10,000-block test is the next sentence. A project note can accumulate plans, research, and months of decisions. We want you to be able to stop anywhere in it and keep writing.

For the algorithms behind these results, read inside our native block editor. Our native editor stack explains the platform interfaces. You can try the iPhone app while we continue building for Mac.