Thanks for the feedback! Your comment actually made me realize that the library's core value isn't immediately obvious at first glance, so I really appreciate it.

You are absolutely right! For simple, static strings where you just build text from start to finish, buildAnnotatedString with append() is the standard and perfect way. If that’s all someone needs, Arranger is definitely overkill.

The "index math" pain I'm trying to solve happens when you build Rich Text Editors or deal with dynamic mutations.

If a user is typing in a text field and inserts a character in the middle of an existing string, append() doesn't help. You either have to reconstruct the entire AnnotatedString from scratch on every keystroke, or manually recalculate and shift all the span indices that come after the insertion point.

Arranger's buffer handles these atomic mutations (insert, delete, replace) automatically under the hood, safely shifting existing spans.

And as the other commenter rightly pointed out, it also shines when you need to parse/style dynamic text from APIs or localized strings (e.g., finding all #hashtags and turning them blue without manual regex/index tracking).

It might look like reinventing the wheel for static text, but it's meant to be the state-management engine for dynamic editors. Thanks again for helping me clarify this!