Thanks Ziqiao — this matches what I landed on. I ran into these same challenges building my own TextKit 2-based editor and ended up on exactly the display-attributes approach you describe (NSTextContentStorageDelegate.textContentStorage(_:textParagraphWith:) returning an NSTextParagraph with resolved attributes, backing store left untouched). It's solid and the per-paragraph performance is fine. One thing worth adding for anyone finding this thread: the delegate is re-invoked automatically when a paragraph is edited, which is perfect for syntax highlighting (appearance is a function of the text). But if your highlight changes without a text edit — Dark Mode, Dynamic Type, a search/selection-driven highlight — nothing re-vends the paragraph and it goes stale. The fix that's been reliable for me is to change the input my resolver reads, then call invalidateLayoutForRange: on the affected range (scope it to the paragraph for per-keystroke changes; whole document is fine for rare global changes like trait changes). Notably, invalidateLayoutForRange: does re-trigger the content-storage delegate, even though invalidateRenderingAttributes(for:) doesn't redraw — which lines up with the rendering-attributes bug you confirmed; the layout-invalidation route is the one that works. Full working example if it's useful: TextKit2-Editor: see SXTextStorageDelegate (the vending) and handleTraitChange in SXTextViewController (the forced re-vend).

Yes — this is exactly what TextKit 2 was built for, and it largely retires the custom UIScrollView + tile-rendering approach. Since iOS 15, UITextView is backed by TextKit 2 (NSTextLayoutManager) by default. The key piece for your case is NSTextViewportLayoutController: TextKit 2 lays out only the text fragments inside the visible viewport (plus a small over-scroll margin), not the whole document. So a long chapter doesn't get laid out up front, and you're no longer fighting the old coordinate ceiling the way TextKit 1 / a single giant canvas did. You get selection handles, the loupe, link interaction, Dynamic Type, etc. for free, because it's a real UITextView. One important gotcha: a UITextView only stays on TextKit 2 if you never touch the legacy NSLayoutManager. Accessing the .layoutManager property triggers an automatic, permanent downgrade to TextKit 1 (and you lose viewport layout). Use .textLayoutManager / .textContentManager instead, or create it explicitly with init(usingTextLayoutManager: true). For truly book-length (not chapter-length) content you may still segment documents, but for a scrolling chapter a TextKit 2 text view should handle it smoothly without the custom scroll plumbing. If it helps to see the moving parts in a real project, I recently open-sourced a TextKit 2 editor in Objective-C — it leans on the resolve-at-render / viewport model and might save you some spelunking: TextKit2-Editor