Sona kadar yerel, ta ki metne ihtiyaç duyulana kadar

• macOS’ta yalnızca SwiftUI ile Markdown sohbet arayüzü oluşturulduğunda temel performans belli bir seviyeye ulaşıyor, ancak belgenin tamamını seçmeyi desteklemek zorlaşıyor
• NSTextView ve TextKit 2’ye geçildiğinde SwiftUI tarafındaki test ve performans çalışmalarının çoğu kaybediliyor ve akış halinde gelen girdide CPU sıçramaları oluşuyor
• NSCollectionView ile yeniden uygulama yapmak hücre titremesine yol açıyor; saf TextKit 2 de performans olarak fena olmasa da streaming ile entegrasyonu zayıf kalıyor
• WebKit, Markdown işleme, performans, tipografi ve kontrol seviyesi açısından genel olarak daha iyi uyum sağlıyor; Electron’da da metin işlemleri varsayılan olarak çalışıyor
• Uzun sohbetler ve zengin metinde SwiftUI ile Apple’ın yerel SDK’ları sınıra dönüşürken, web tabanlı yaklaşım metin ve render modeli açısından avantajlı hale geliyor

---

Yerel macOS Markdown sohbet arayüzünün sınırları

• Yalnızca SwiftUI ile Markdown destekleyen basit bir sohbet arayüzü oluşturulduğunda temel performans belirli bir düzeyde mümkün olsa da, SwiftUI primitive’leriyle kurulan Markdown belgesinin tamamını seçmek mümkün olmuyor
• NSTextView’a geçildiğinde TextKit 2 desteği kazanılıyor, ancak SwiftUI’da yapılmış test ve performans çalışmalarının büyük kısmı kaybediliyor ve SwiftUI ile de iyi uyuşmuyor
• Model yanıtları NSTextView içine akışlı biçimde verildiğinde CPU sıçramaları yaşanıyor
• NSCollectionView ile yeniden uygulansa bile hücreler sürekli titriyor ve bu, tasarım gereği kaçınılması zor bir davranış olarak kalıyor
• Saf TextKit 2 prototipi performans açısından kabul edilebilir olsa da streaming hâlâ zayıf ve modern bileşenlerle de iyi uyum sağlamıyor
• SwiftUI tamamen kaldırılıp yalnızca AppKit kullanılsa bile büyüyen metin parçalarını elle yönetmek gerekiyor ve ancak pek çok şey bozulmuş durumdayken metin seçimi mümkün hale geliyor
• Temel macOS davranışına benzer bir seviyeye ulaşmak için kullanıcıların doğal olarak beklediği bağlam menüsü, sözlük arama, seçim, erişilebilirlik ve metin etkileşimi gibi işlevleri yeniden eşleştirmek gerekiyor

WebKit ve Electron’un daha iyi uyduğu noktalar

• Markdown, WebKit ile işlendiğinde dikkat edilmesi gereken bazı noktalar olsa da genel olarak iyi çalışıyor; performans ve tipografi güçlü, kontrol seviyesi de yeterli
• Basit bir Electron projesi oluşturulduğunda metin işlemleri, Markdown render etme ve iyi tipografi varsayılan olarak çalışıyor; ayrıca saf TextKit 2 uygulamasında elde edilmesi daha zor olan performans da sağlanabiliyor
• Electron’da da macOS entegrasyonu sunuluyor; birkaç satır kodla gösterişli Git diff’leri render edilebiliyor ve diffs.com bunun örneklerinden biri
• SwiftUI, AppKit, TextKit ve WebKit’in tümü değerlendirilse bile “Markdown destekleyen ve tüm mesajın seçilebildiği bir sohbet” gibi basit bir gereksinimi gerçekten karşılamak zor görünüyor
• Sohbet, uzun biçimli zengin metin ve esnek tipografinin önemli olduğu yeni uygulamaların neden web tabanlı yöne gittiği daha net hale geliyor
• SwiftUI, kaydırmanın çok yoğun olmadığı basit ekranlar için uygun ve Swift de performansın kritik olduğu bölümlerde hâlâ yararlı
• Electron veya React Native, yerel birlikte çalışabilirlik sayesinde ciddi performans sunarken daha iyi bir metin ve render modeli koruyabiliyor
• Uzun biçimli sohbetler için zengin metin render etmede SwiftUI ve Apple’ın yerel SDK’ları avantaj değil, kısıt haline geliyor
• İlgili tartışmalar: Hacker News, Lobsters

[GN⁺]

Hacker News görüşleri

• Kısa süre önce TextKit 2 kullanan bir iOS metin düzenleyicisi yayınladım ve 5.000 satırlık dosyalarda bile performans çok iyi
  Testi Project Gutenberg’den Moby Dick ile yaptım; uygulamayı 2025 Ağustos ile 2026 Nisan arasında geliştirdim ve geliştirme hâlâ sürüyor
  Her tuş vuruşunda yeniden stillendirme 8 ms içinde tamamlanıyor; debounce ya da gecikmeli render olmadan hızlı 20 giriş bile, her girişten sonra tüm yeniden stillendirme dahil, 150 ms içinde işleniyor
  Etiketler ve boolean arama 20 ms içinde bitiyor; yalnızca görünür alanı render etmek, tüm belgeyi stillendirmekten 25 kat daha hızlı ve 120Hz ekran yenilemeyi de destekliyor
  Uygulamanın dosya boyutu 1.0 sürümünde 722 KB’tı; daha fazla özellik içeren 1.1 de yaklaşık 950 KB görünüyor
  Bu iOS’ta mümkünse macOS’ta yaklaşık 10 kat daha kolay olması gerekir
  https://www.gingerbeardman.com/apps/papertrail/

  • Ücretli bir ürünün temel özelliği editörse bu anlaşılır. Ama Markdown render etme uygulamanın ana işlevi bile değilken ve 2026’da kullanıcıların beklediği bir kullanım kolaylığına daha yakınken, bunun için 8 ay ve devam eden geliştirme gerektiren düşük seviyeli özel bir uygulama yazma zihniyetine girmek garip
    “İmkânsız” demek istemiyorum; sadece insanların neden böyle şeylerde web teknolojilerini native yerine seçtiğini anlıyorum. İnsan ürün yapmak istiyor, sistemin sınırlarıyla dövüşmek değil
  • 2012’de NSString ve attributed string’lerle interaktif bir roman yaptım, terk edilmiş düşük seviyeli glyph API’leriyle bir roguelike geliştirdim, SwiftUI ile Markdown destekli iki sohbet uygulaması ve iOS hileleriyle dolu bir idle game yazdım; buradan bakınca bu tepkiyi sonunda ustalık meselesi diye özetliyorum
  • 5.000 satır gerçekten çok küçük bir boyut, o yüzden bu açıklama kafa karıştırıcı. Test edildiği söylenen Moby Dick de 22.000’den fazla satır gibi görünüyor ve Windows’un varsayılan Not Defteri bile bu boyuttaki dosyada takılmıyor
    Bir metin görüntüleyicisinin en azından bunun bir iki büyüklük mertebesi üstündeki dosyaları ele alabilmesi gerekir. Yüz binlerce satırlık JSON dosyaları yaygın, CSV ve log dosyaları ise daha da uzun
  • Sorun büyük ihtimalle SwiftUI’nin Mac implementasyonu. Bu tür bir uygulama için SwiftUI-on-Catalyst daha iyi bile olabilir ama muhtemelen başka sorunlar çıkaracaktır
  • iOS’ta oluyorsa macOS’ta 10 kat daha kolaydır sözüne ciddi şekilde şüpheyle yaklaşıyorum. Hatta tam tersi olabilir gibi geliyor; gerçekten bilen birinden duymak isterim

• Eskiden webview yerine native API kullanmanın nedeni performanstı, ama artık her zaman öyle görünmüyor
  Tarayıcı render motorları oldukça olgunlaştı, GPU hızlandırma yoğun biçimde kullanılıyor ve 10 yılı aşkın süredir şişkin web uygulamalarıyla stres testinden geçti
  Buna karşılık SwiftUI pek de hızlı hissettirmiyor. Apple’ın yakın zamanda baştan yaptığı Sistem Ayarları bile arayüzü checkbox satırları etrafında sadeleştirmişken, bölümler arası geçişler bazen us-east-1’den web sayfası yüklüyormuş gibi daha takılarak oluyor

  • Buradaki sorun genel olarak native uygulamalar değil, SwiftUI
    Qt C++ ve QML ile native uygulamalar yaptım ve benzer web uygulamalarından çok daha hızlı olup çok daha az RAM kullandıklarını gösterdim
    O yüzden genel olarak web uygulamaları, iyi tasarlanmış native uygulamalardan daha yavaş ve daha kaynak tüketen yapılar
    [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
    [2] https://x.com/daniel_nguyenx/status/1734495508746702936
    [3] https://rubymamistvalove.com/block-editor#8-performance
  • Yine de native uygulamalarla en hafif tarayıcı uygulamaları arasında büyük fark var ve bu düşük güçteki cihazlarda daha belirgin
    Eskiden web geliştiricisiydim ama son 6-12 aydır native çapraz platform uygulamalar yapmaya başladım; basit işlerde bile performans farkı oldukça büyük
  • Tarayıcılar eski donanımda berbat. Eski Chromebook’lar yaygın ve hafif kullanım ya da belirli amaçlar için donanımları fena değil, ama tarayıcı gerçekten çok yavaş çalışıyor
  • Basit web uygulamalarında sorun olmayabilir ama karmaşık uygulamalarda gözle görülür yavaşlama var. Jira gibi bir canavara bile gitmeye gerek yok; VS Code gibi iyi optimize edilmiş uygulamalarda bile native uygulamalara göre daha düşük bir performans tavanı var
  • WebView da sonuçta “native”
    Binlerce insan-yıllık optimizasyonu ve gerçek dünyada yüz milyonlarca insan-yıllık doğrulamayı çöpe atıp, daha kötü bir metin render motorunu yeniden yazalım diye düşünmek garip

• macOS’ta WebKit native bir OS framework’ü. Markdown render etmek için WebKit kullanmak tamamen makul görünüyor
  Elbette her şeyi WebKit ile render etmek, her şeyi PDFKit ile render etmek kadar anlamsız olurdu. Ama bir Markdown görünümü için WebKit mantıklı bir tercih; bu da hemen gidip Chromium tabanlı bir web uygulamasına geçmek gerektiği anlamına gelmiyor

  • Bir HTML motoru, UI’de render edilmesi en zor şeylerden biri olan zengin metni native UI kütüphanelerinden daha iyi render edebiliyorsa, neden buton ve metin alanı gibi daha kolay şeyleri de onunla render etmeyesin?
    Ayrıca OS X uzun süre UI’yi DisplayPDF/Quartz ile render ediyordu
  • Markdown’ı WebKit ile render etmenin neden uygun olduğunu açıklamak gerekir
  • Orijinal yazar “native”i sadece Swift/ObjC ilkel öğelerini kullanmak olarak görüyor gibi
    WebKit başka platformlarda da var diye hile mi sayılıyor? O zaman Java da kullanılabilir
  • Zengin metin render etmek için neden WebKit kullanmanın beklenmesi gerektiğini anlamıyorum
    Metni HTML/CSS/JS render edicisiyle çizmek “tamamen uygun”sa, uygun olmayan alan ne? Neden her şeyi onunla render etmiyoruz?
    “Metin render etmek uygun ama her şeyi render etmek saçma” sonucuna giden mantığı anlamıyorum
  • Aslında şu anda ilerleyen çözüm, nihai Markdown’ı ve stream edilen içeriği WebKit ile render etmek
    WebKit’in macOS’ta native bir OS framework’ü olduğuna katılıyorum; o anlamda bu da “native”
    Ama bu aynı zamanda daha büyük noktayı da destekliyor: zengin metin, Markdown, seçim, tipografi ve uzun biçimli formatlı içeriği düzgün ele almak için web teknolojileri hızla tek pratik seçenek hâline geliyor
    Markdown görünümü için WebKit kullanmak yanlış değil; hatta muhtemelen en mantıklı seçim. Sorun, buradaki “native” çözümün fiilen bir web render çözümü olması
    Her WKWebView, kendi performans ve bellek ek yüküyle gelen bir WebKit motoru taşır; bu yüzden etrafa serpiştirilip bedava native macOS bileşeni gibi görülemez
    SwiftUI / AppKit / TextKit’in bu tür arayüzlerde “git WebKit kullan”dan daha temiz, modern ve birleştirilebilir bir yol sunmaması can sıkıcı

• “Markdown içeren bir sohbette tüm mesajın seçilebilmesi” gibi temel bir şeyin yapılamaması mantıksız geliyor
  SwiftUI’da olgun Markdown render ediciler kullanılabiliyor. https://github.com/gonzalezreal/swift-markdown-ui ve onun yeni nesil alternatifi https://github.com/gonzalezreal/textual buna örnek
  Bizzat kullandım ve sorun yaşamadım. Swift ya da SwiftUI seven biri değilim, hatta Objective-C tercih eden biraz aptal biriyim; yine de bunu LLM yardımı olmadan yaptım

  • Bugün daha erken saatte Textual’ı denedim ve sonuçlar pek iyi değildi
    Statik, tamamlanmış Markdown kaydırması yeni odak probe’unu geçemedi; p95 18.86 ms ile 16.7 ms bütçesini aştı ve maksimum 232.49 ms gördü
    Uzun canlı Markdown/kod güncelleme yolu da başarısız oldu; p95 59.33 ms’ye karşı 16.7 ms, maksimum 75.94 ms. Bu, güncelleme sırasında büyük zengin metin yüzeylerini ele alan ayrı ama ilişkili bir stres senaryosu
    Uzun geçmiş genişletme teknik olarak geçiyor ama akıcı kareler sayılmaz: 120 turda p95 21.35 ms, 500 turda 23.11 ms, 1000 turda 36.77 ms
    Kötü değil ama benim çözümümden biraz daha yavaş ve görünen performans farkı büyük ölçüde Textual implementasyonundan çok SwiftUI ile ilgili
  • Yeni metin stream edilirken bunu titreme olmadan yapabiliyor mu?
  • Markdown belgesini yalnızca bir kez render ediyorsanız ya da belge kısa ve basitse olabilir
    Geçmişte uygulamamda swift-markdown-ui kullandım ama performansı wkwebview’in yanına bile yaklaşamadı. Büyük tablolar, kod blokları ve iç içe alıntılar gibi zorlu öğeler içeren büyük belgeleri stream edince beachball bile görebiliyordum; wkwebview kullanırken bunlar hiç olmadı
  • İlk kütüphane görünüşe göre Claude iOS uygulaması tarafından kullanılıyor ve metin seçimiyle stream etme de mümkünken performansı da iyi gibi duruyor
  • Kullanıcı açısından eski HTML tabanlı olmayan uygulamaların “kurallara” uymadığı fark ediliyor. Seçilebilir olması gereken metin seçilemiyor ya da control/option C ile kopyalanamıyor
    Sonra tarayıcıların ve onların temel teknolojilerinin arayüze yeni bir paradigma getirdiğini, native UI framework’lerinin de buna yetişemediğini fark ettim
    Web tabanlı uygulamalara kıyasla native uygulamaları tercih eden biri olarak bile böyle hissediyorum

• Ya kodu gösterin ya da çıkın. Şu anda bile Markdown render etme ve stream edilen metni düzgün işleme konusunda çok sayıda native Mac/iOS uygulaması var
  Burada tam olarak neyin mazeret gösterildiğini merak ediyorum

  • “SwiftUI ilkel öğeleriyle oluşturulmuş tüm Markdown belgesini seçmek istiyorum” deniyor ama bunu kim ister? Böyle bir ürün kararı fiilen belge editörü yapmak anlamına gelir; bu onlarca yıldır zor bir alan ve LLM sohbet arayüzünün kapsamını aşıyor gibi
    Çoğu uygulama, art arda gelen blokların her biri içinde seçim desteği verip tüm mesaj için ayrıca kopyalama düğmesi koyma yönünde karar kıldı
  • WebView olmadan mümkünse kodu paylaşmak yeterli olur

• İşin ilginç yanı, Apple’ın da geçmişte bunu yapmış olması
  Eski macOS / AppKit, native NSTextField içindeki zengin metni render etmek için WebKit kullanıyordu. Metin zor bir problem
  Ayrıca native WebView çok hızlı ve hafif; onu metin yerleşim motoru olarak kullanmak da garip değil. Bir tablodaki her satır için ayrı bir WebView kullansanız bile performans harika olabilir
  Mac için iMessage da WebView kullanıyordu, Adium da öyleydi. Zengin/işaretleme tabanlı metin render ediyorsanız HTML tamamen doğru araç

  • Burada iOS ve Mac OS karıştırılıyor
    Mac hiçbir zaman NSTextField render etmek için WebKit kullanmadı. iOS ilk yapıldığında, UIKit kontrolleri de dahil olmak üzere genel olarak metin render edici olarak WebKit kullanıyordu ve buna “sweet solution” deniyordu
    Ama bunun fazla ağır ve zahmetli olduğu ortaya çıkınca yerini Core Text/AppKit tarzı metin render yaklaşımı aldı
  • Orijinal metindeki akış biraz tuhaf
    Karmaşık native metin render etmenin zor olduğunu keşfediyor, sonra düşük seviyeli yöntemle metin render edip native etkileşimleri yeniden uygulamak zorunda kaldığından şikâyet ediyor
    WebKit’i deneyince çok iyi çalışıyor, ama sonra onu bırakıp yine native etkileşimleri yeniden kurmak zorunda olduğu bir duruma dönüyor
    Ben olsam WebKit’in iyi çalıştığı noktada dururdum

• 2015’te junior mühendisken, bir iOS uygulamasında paragraf içindeki tıklanabilir bağlantıları render etmem istenmişti diye hatırlıyorum
  Swift’in yeni çıktığı dönemdi; tamamen ObjC/UIKit yığını kullanılıyordu ve tam bir kâbustu. Zor bela çalıştırabilmiştim
  2016 civarı sonrasında iOS’a neredeyse hiç dokunmadım; yeni SwiftUI’da bunun artık doğal olarak yerleşik geldiğini varsaymıştım ama öyle değilse bu oldukça çılgınca

  • Kelimenin tam anlamıyla Link diye bir şey var
    https://developer.apple.com/documentation/swiftui/link
    Bundan daha kolay nasıl yapılabilir bilmiyorum
  • Qt bunu 10 yıl önce bile oldukça kolay yapıyordu
  • NSLinkAttributeName yok muydu?
  • Attributed text’in bunu eskiden beri iyi hallettiğini sanıyordum; öyle değil miydi?
  • Paragraf içinde tıklanabilir bağlantılar istemek zaten başlı başına kötü bir fikirdi

• “Basit ekranların dışına çıkınca native’in hâlâ bu kadar olgunlaşmamış olması” aslında beklenen bir şey
  İnsanlar yeterli emeği vermezse onun olgunlaşmasını bekleyemezsiniz
  Daha fazla çaba web teknolojilerine aktığı için insanlar da oraya kilitleniyor. Native’e bakıp “yeterince gelişmemiş” diyorlar, sonra gidip daha fazla web geliştirme yapıyorlar; döngü böyle sürüyor
  Tarayıcıda zaten “çalışıyor” diye native’i iyileştirmeye ciddi emek harcamak isteyen neredeyse kimse kalmadı

  • Yine de native UI toolkit’leri ticari ürünler değil mi? İnsanların kendilerini ikna etmesi gereken bir şey değil; onların insanlara satış yapması gereken bir alan
    Web tarafının daha olgun olmasının nedenlerinden biri de büyük ticari OS üreticilerinin zamanın gerisinde kalmayı seçmiş olması. Windows UI toolkit’leri gerçekten berbat
  • Katılıyorum. Sonuçta Swift içinde Markdown’ı hızlı ele almak için yeterli çaba gösterilmediğinden şikâyet ediyor ama kendisi de buna katkı sunmaya çalışmıyor

• Ben de AI sohbet uygulamamda neredeyse aynı deneyimi yaşadım. Hiçbir şey doğru düzgün çalışmıyor
  Markdown render etme yavaş ve takılıyor, stream etme yavaş ve takılıyor, her şey UI’yi donduruyor
  GitHub’daki popüler UIKit ve SwiftUI metin editörü bileşenlerinden en az 5 tanesini denedim; hepsi bir şekilde bozuktu ya da bug’lıydı ve yavaştı. İnanılmaz

• Bu zor bir problem. Qt C++ ve QML ile sıfırdan bir blok editörü yaparken bunu nasıl çözdüğümü uzun uzun yazdım
  Kesintili bloklar arasında seçim, imlecin altındaki kaynak Markdown’ı gösterme ve farklı delegate boyutları gibi benzer sorunlar yaşadım
  O süreçte öğrendiklerime dayanarak stream eden Markdown ayrıştırıcısına sahip native bir LLM istemcisi geliştiriyorum
  [1] https://rubymamistvalove.com/block-editor
  [2] https://www.get-vox.com

[GN⁺]

Lobste.rs yorumları

• Karmaşık metin yerleşimi için webview'in uygun olduğuna katılıyorum, ama kullanım kolaylığı dışında özellikle neden Electron'a kadar gitmek gerektiğinden pek emin değilim
  Electron aslında WebView'i saran bir wrapper; ancak tüm Chromium motorunu da beraberinde getirdiği için, kullanım kolaylığının bedeli olarak uygulama boyutu fazla şişiyor
  2001~2002'de iChat'in ikonik konuşma balonu metin yerleşimini NSTextView ve türlü hilelerle hayata geçirmiştim; AppKit metin tasarımcısı Hideki Itamura'nın yardımıyla bile epey uğraştırmıştı. Şimdi ise HTML+CSS ile oldukça basit hale geldi
  • Birden fazla sistemi desteklerken sonuçta basitlik önemli
    Tauri kullanan bir uygulamada yer almıştım; bunu Electron'da Chromium kullanacak şekilde değiştirince çok daha iyi çalıştı. Özellikle win7'den win11'e kadar çok geniş bir aralığı hedeflemesi de önemliydi
    Tauri tarafı sistem webview'ini kullanmasıyla cazip görünüyor, ama Windows'ta Chrome ya da Edge, macOS'ta Safari, diğer ortamlarda ise biraz şansa kalıyor. Sonuçta öngörülebilirlik ve olgunluk kazandı; nedeni tam bilinmese de performans da daha iyiydi
  • Bence bu kişisel bir tercih. İster uygulama boyutu ister RAM kullanımı olsun, kullanım kolaylığının bedelini ödemeye hazırsanız, görünüşe göre Visual Studio Code gibi uygulamaların milyonlarca kullanıcısı da buna katılıyor
    Sonuçta amaç htop grafiğini tatmin etmekten çok daha iyi yazılım istemek
    Blog yazısının özü “herkes Electron seçmeli” değil; kaynak ve parası olan şirketlerin neden hâlâ Electron ya da web teknolojilerini seçtiğini artık anladığı. En azından bana göre, doğru yerlerde taviz vererek iyi bir kullanıcı deneyimi sunuyor
    Apple'ın TextKit 2'sini ya da diğer native metin framework'lerini savunan çok kişi var, ama yalnızca Apple SDK'larıyla yapılmış popüler ve yüksek performanslı bir metin editörü neredeyse yok. Xcode bunu oldukça iyi yapıyor ve muhtemelen gerçek dünyadaki tek örneğe en yakın olanı. Zed, Sublime Text, Visual Studio Code ve JetBrains IDE'lerinin hepsi bir nedenle kendi metin render etme çözümlerini kullanıyor
• Sorunlardan biri de yazılım yapan insanların, dünyadaki en iyi bilgisayar ve telefonların üst %0,1'lik diliminde geliştirme yapması
  Bu yüzden en kötü yöntemle inşa edilse bile kendi ortamlarında sorun yokmuş gibi görünebilir
  Buna karşılık çok daha düşük özellikli cihazlar kullanan geri kalan herkes şişkin ve yavaş yazılımları taşımaya devam ediyor
• GTK/Qt tarafında bugünlerde durumun nasıl olduğunu merak ediyorum. GUI ile uğraşmayalı uzun zaman oldu
  • Anladığım kadarıyla bu iş Qt ile de webview olmadan yapılabilir
    Yalnız yazar burada oraya kadar keşfe çıkmamış gibi görünüyor
• Electron ile Flutter karşılaştırılsa nasıl olur merak ediyorum
  Dışarıdan bakınca Flutter, “Chromium'dan renderer olarak sadece Skia'yı bırakıp GUI uygulamalarında kullansak ne olur?” sorusuna verilmiş bir yanıt gibi görünüyor. Electron'dan daha hafif ama benzer yeteneklere sahip bir cross-platform araç olması gerekir gibi
• https://github.com/stevengharris/MarkupEditor yazarı, bu yazının şu anda mümkün çözümlerden biri olarak oldukça iyi olduğunu öne sürüyor: https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-promised-land/
  • Ama MarkupEditor TextKit2 değil, WebView kullanıyor. README'de de MarkupEditor'ün tek bir contentEditable DIV kullanan bir HTML belgesiyle etkileşime girdiği ve WKWebView'in bir alt sınıfını kullandığı yazıyor
    İronik olan şu ki Apple'ın native metin motoru, HTML DOM ağacından çok daha iyi bir veri modeli kullanıyor; yani string'ler ve run-length encoded stil öznitelikleri
    DOM içinde metin düzenlemek neredeyse bir kâbus, çünkü seçim alanı çoğu zaman birden çok katmandaki birden fazla öğenin üzerinden geçiyor ve bu yüzden aşırı karmaşık şekilde bölüp birleştirmek gerekiyor. Eskiden contenteditable desteği eklenmiş bir Safari build'ine ilk dokunduğumda tonla bug raporu göndermiştim; bugün bile pek çok web rich text editörü liste öğelerini kesip yapıştırırken bozuluyor
    Sonuçta sanki 90'lar~2000'lerdeki CISC ile RISC meselesine benzer bir durum yaşandı. “Daha aşağı” görülen yapı daha fazla kaynak aldığı için sonunda daha üstün bir uygulama ortaya çıkarmış oldu