The update for DTRichTextEditor adds support for building for arm64 and fixes two bugs.
Update: If you have trouble building via CocoaPods please make sure that you have version 0.23 and also refresh your pod specs. I had to – once more – modify the spec to fix a build problem. Sorry for the inconvenience.
I finally got around to updating the DTRichTextEditor time-limited Demo for Version 1.5. The new version broke a few items in the Demo because of the introduction of the text attachments class cluster.
The Demo is available on GitHub, the only other ingredient you need is a time-limited binary build of the DTRichTextEditor.framework.
Today we are releasing the 1.5 version of our rich text components. This marks the second unified release where several parts of our rich text eco system are maturing in lock-step.
For the most part these improvements and enhancements were funded from exceptional sales of DTRichTextEditor as well as several sponsors who stepped forward to allow me to finally get support for lists implemented.
From what I can tell the clients who licensed the editor are way more willing to contribute funds to something they have already paid for, than for enhancing the – otherwise free with attribution – DTCoreText.
You probably have looked at CocoaPods by now and found it to be a great way to quickly pull together all your favorite Open Source components for an app. After our recent move to Git I researched some more and found that it is exceptionally easy to also provide specs for your closed source private code.
Update: Updated Resource Bundle generation use the new syntax of CocoaPods 0.18.
Beginning with version 1.4 we will advance the version tags on DTCoreText and DTRichTextEditor in sync. DTCoreText is in charge of HTML parsing, display and HTML generation inside the editor component and thus all the changes done there are indirectly benefitting editor users as well.
I’ve begun to aggregate issues on both GitHub and our own private GitLab instance via milestones. These are the grouping unit collecting issues so that you can tell from which version onward these fixes or enhancements are available. Each milestone will become a tag, once it is completed and will represent a stable version.