I don't know where's the improvements, give it has all the limitations, now scaled to rich text. That's not the direction that this component should get. It need radical new API that is not much compatible with SwiftUI API
totally. the there's a lot complexity that adds up to the overall performance issues. and TextKit 2 IS pretty bad at things. especially public API is pretty bad - that result in my case need to workaround things that I should've not. I agree with the general sentiment et all. I also still believe there is a place without bringing the whole browser machine to render text, and have text under control - but without relying on the "TextKit" level. That's the next thing I'm researching right now.
SwiftUI, (but not specifically "SwiftUI", more of paradigm) is not the right tool to incremental changes of large portion of data, and SwiftUI specifically is very bad at it and offer no good API to make incremental changes more optimal. That's one of the reason behind why Apple to this day did not ship usable SwiftUI text view component.
ackckcually, technically Xcode is spare, but for the convenience and due to Mac/iOS SDK distribution licensing, that's the only way to obtain the SDK on the machine.
Linux runs in a lightweight VM.