15 years in the past, I began my first open supply mission on GitHub. Initially it was known as NSAttributedString-Additions-for-HTML however later I renamed it to DTCoreText. I had switched to upkeep mode 8 years in the past, as a result of I had no real interest in placing extra work into an Goal-C code base.
Apart from of the previous language there have been too many dependencies into much more Goal-C frameworks, specifically DTFoundation which held the libxml2-based parser which is utilized by DTCoreText and lots of workarounds for compiling on older working techniques from a time earlier than ARC.
So for the previous decade this guide was closed for me. I freely admit that I had discovered a brand new love in Swift and it with all of the happiness that this supplied I simply couldn’t reopen it. For a very long time I additionally soothed myself with Apple telling us that no one is forcing you emigrate to Swift, as a result of Goal-C libraries fortunately coexist with Swift.
However the fact of the matter is that Swift continued to develop and get pretter yearly whereas Goal-C remained an unsightly hack. In the direction of the tip of final 12 months, I wanted to parse some HTML for producing markdown from it, for my Swift Brokers. That brought about me to revisit libxml2’s relaxed HTML parsing mode. This time round I wrapped this C library in Swift and it felt like a breath of contemporary air. In order that’s why I added it to SwiftText, my assortment of Textual content manipulation utilities.
And this planted the thought in the back of my thoughts: if coding fashions have gotten so good, possibly one is as much as the duty of absolutely migrating DTCoreText to Swift?
Claude Code Opus 4.6 did it!
The large plus from having an ideal many unit exams in my OSS initiatives is that you’ve got a simple solution to decide correctness of the migration. If you happen to may give a coding agent a deterministic solution to know when it’s carried out, then it might work on a job for hours till it’s actually carried out.
So I adopted my hunch and tasked Opus (by way of Claude Code) to try a migration. I had my doubts, however a number of hours later all unit exams have been passing and even the Demo App – which stays in Goal-C for the primary model – remains to be performing flawless.
So the primary migration step was emigrate all of the unit exams to Swift Testing. The second was to tear out the prior dependency to DTFoundation with the older HTML parser. And whereas doing so to additionally take away help for OS variations which can be not supported by the compiler. The brand new parser now makes use of an asynchronous stream of parsing occasions as an alternative of delegate calls, as to permit it being pure Swift.
After that we migrated to make use of native varieties the place beforehand I had my very own. Up till the very finish we had an choice to activate UIKit-compatibly attributes which was off by default. That’s now gone as nicely many extra crufty workarounds. Internally the attributed string builder not has any GCD-tech, however is totally primarily based on structured concurrency, together with an async technology perform that helps cancellation.
And as a virtually free bonus there’s now additionally a bridge from NSAttributedString to the SwiftUI worth sort AttributedString – so now you can use normal textual content views with the generated strings.
Can we nonetheless want DTCoreText?
Effectively, to be trustworthy I’ve been asking myself the identical query for upwards of 10 years now. There are fairly a number of issues that fashionable TextKit nonetheless doesn’t do.
TextKit solely helps a single shadow, masses embedded photos solely synchronously, doesn’t help photos as listing bullets, no textual content packing containers and no customized HTML objects. Oh and no customized subviews. And doubtless a number of gadgets extra. I don’t know the way nicely TextKit helps CSS inheritance. DTCoreText was all the time making an attempt to be extra devoted to the HTML.
Then there’s the subject of tables. It could in all probability be not too troublesome for a coding agent to implement one thing. If I bear in mind appropriately then the Apple-provided parsing capabilities did parse HTML tables on Mac. Now that we aren’t hindered by Goal-C any extra and we’ve coding brokers, the world is our oyster!
Conclusion
In case you are nonetheless caught with Goal-C, don’t fear, DTCoreText remains to be callable from there. Internally it’s absolutely Swift, however the surfaces which may must be seen from “previous code” nonetheless exist.
I did shut all stale open pull requests on the mission in preparation for the migration. Now on Swift it will likely be a lot simpler to repair points or implement new performance since that’s carried out by brokers lately.
Regardless I’d have an interest to listen to from people who find themselves nonetheless actively utilizing DTCoreText of their initiatives. As a result of as I stated, there could be some legit benefits that also exist over Apple-provided frameworks.
The subsequent steps could be to implement a SwiftUI view that helps the extra DTCoreText performance and presumably migrating the Demo App additionally to Swift. What else would you want?
Associated
Classes: Administrative
