krzyzanowskim

the Web is probably the most limited platform today to build custom text editor, in terms of text layout, interaction and all the small bits that may matter. It is still lacking proper API to interact with the OS input system outside the browser built-in text capabilities. That's why the <canvas> approach is so painful, and everything else is "limited" by the HMTL and Browser implementation details.

Very ambitious and fantastic pet project. In my opinion doomed to share the Flutter fate that has similar goal of reimplementing the entire OS UI layer (liquid glass hit flutter very hard for that reason). Technically that "does not scale" after a while, given it's reverse engineering effort. It is far from pixel perfect today, and (my prediction) will not improve much. some aspects are impossible to copy Apple design pixel perfect on the UI level, not to mention on how SwiftUI modifiers may behave. Great work nonetheless

Flutter is not the "right way", due to the nature of Flutter being a lousy reimplementation of a UI frameworks.

Marketing departament went ahead and drop "battle-tested product" nobody ever battle tested.

I think people should use anything but SwiftUI.TextEditor is my current stance

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.

"skills issue" but also "native" frameworks are lacking polished API. On macOS TextKit2 is unfortunately kinda broken, how do I know? I reimplemented TextView with it https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-prom...

becase there is only one Notepad.exe https://notepadexe.com on the mac

I almost predicted that on Friday https://blog.krzyzanowskim.com/2026/03/30/shipping-snake-oil... so close to when comedy become reality

until then, the https://CommanderAI.app tries to fill the gap on Mac

I think you should stick to what works for you best

dont see it in crash logs so far. Drop me email with whathever you have, I'll try to trace it down. Make sure you download latest build.

it is a coding Notepad that also execute the code

Notepad++ is already taken. that's sad

there is open contest for different name. mind to chime in?

that's not great, mind drop me an email on support? update: hotfix in making

> Apple's on-device models for the AI?

no. Apple on-device models are not suitable for such a task. It uses a different model (I don't stick to one model in particular, as it may change)

> Does Swift have UI capabilities on Linux?

No. there are projects inspired by SwiftUI: https://github.com/stackotter/swift-cross-ui or https://git.aparoksha.dev/aparoksha/adwaita-swift (GNOME)

The contest for a name, that is not lame AF, just started

yes! but that's leftover from the previous version of the site that was pixelated

if Microsoft can name a plain text editor Visual Studio, I can name mine Notepad.exe

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.

yes. same!

I should not give you advice against my interest. "run" is paywalled after some time.

the plugged-in device is not supported as of today.

I don't disagree necessarily. I also love the name with all my heart

it works really great with https://kindavim.app/ which adds vim everywhere. problem solved.

annoyingly enough, the API has some sort of background layout support. I don't think it works well, though. I tried to use it, but it did not improve the "main thread" operations sigificantly to have an impact of fast scrolling scenario - I suspect it may not work actually

we could build a space rocket with it if we only knew how to use it, so it would not glitch

as long as we deal with estimated values, it is inescapable. the best we can do is tune the estimate calculations and tweak heuristics. that's my understanding of the problem, but I'd love to hear from other experience