15 years in the past, I began my first open supply undertaking 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 little interest in placing extra work into an Goal-C code base.
In addition to 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 plenty of workarounds for compiling on older working techniques from a time earlier than ARC.
So for the previous decade this ebook 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 offered I simply couldn’t reopen it. For a very long time I additionally soothed myself with Apple telling us that no person is forcing you emigrate to Swift, as a result of Goal-C libraries fortunately coexist with Swift.
However the reality of the matter is that Swift continued to develop and get pretter yearly whereas Goal-C remained an unpleasant hack. In the direction of the tip of final yr, 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, perhaps one is as much as the duty of totally migrating DTCoreText to Swift?
Claude Code Opus 4.6 did it!
The large plus from having a fantastic many unit assessments in my OSS initiatives is that you’ve a straightforward technique to decide correctness of the migration. In case you may give a coding agent a deterministic technique to know when it’s carried out, then it may work on a process 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 couple of hours later all unit assessments 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 assessments 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 assist for OS variations which might 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 sorts 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 effectively 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 operate that helps cancellation.
And as a virtually free bonus there’s now additionally a bridge from NSAttributedString to the SwiftUI worth kind AttributedString – so now you can use normal textual content views with the generated strings.
Will we nonetheless want DTCoreText?
Effectively, to be sincere I’ve been asking myself the identical query for upwards of 10 years now. There are fairly a couple of issues that fashionable TextKit nonetheless doesn’t do.
TextKit solely helps a single shadow, masses embedded pictures solely synchronously, doesn’t assist pictures as listing bullets, no textual content packing containers and no customized HTML objects. Oh and no customized subviews. And doubtless a couple of gadgets extra. I don’t know the way effectively TextKit helps CSS inheritance. DTCoreText was at all times attempting to be extra trustworthy to the HTML.
Then there’s the subject of tables. It will in all probability be not too tough for a coding agent to implement one thing. If I keep in mind accurately then the Apple-provided parsing capabilities did parse HTML tables on Mac. Now that we’re not 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 totally Swift, however the surfaces that may must be seen from “previous code” nonetheless exist.
I did shut all stale open pull requests on the undertaking 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 today.
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 mentioned, there is likely to be some professional benefits that also exist over Apple-provided frameworks.
The following steps is likely to be to implement a SwiftUI view that helps the extra DTCoreText performance and probably migrating the Demo App additionally to Swift. What else would you want?
Associated
Classes: Administrative
