Another alternative is FTCoreText ( https://github.com/FuerteInternational/FTCoreText ), which I've had good experience with. Like AttributedMarkdown or Slash, you define NSAttributedString text styles in code. But there are (I believe) two differences which might be significant advantages in some cases.
First, FTCoreText doesn't predefine the tag vocabulary. You just associate your styles with tag names you define, and write your text in a pseudo-XML syntax using those tags. This is good for defining tags with semantics suited to your particular domain.
Second, FTCoreText doesn't use UIKit's NSAttributedString attributes. It uses the more powerful CoreText NSAttributedString attributes, which have been present since iOS5 at least. They are more powerful in one important way: only the CoreText string attributes support defining tab stops. This might seem like an irrelevant corner case, except that (as far as I know) this is the only way to properly define correct text indentation of text in bulleted list items.
The tag vocabulary isn't really predefined. There is a default vocabulary, but it can be easily changed by passing in a different dictionary of tags.
Also, the attributes aren't restricted to UIKit's NSAttributedString attributes (or not by Slash, anyway). You can provide whatever attributes you want, so long as the view you pass the attributed string to understands them.
Wait, why doesn't iOS have the equivalent of the -initWithHTML:documentAttributes method from the AppKit additions? That's been around since, let me check... always. Why would Apple leave it off on the iPhone?
At least with RTF, that seems to be functionality that is generally missing from UIKit. HTML parsing, on the other hand, is already there in WebKit.
The sense I get is that Apple didn't really know what they were doing when they first released the iPhone, didn't actually intend to release an API for it (after all, the initial message to developers was "just build an HTML 5 app") and then rushed one out without properly thinking through its design. And I guess they've been filling the gaps ever sense.
Interesting... I sort of agree. But the strange thing is to start supporting rich text in UIKit controls without providing a sane API for manipulating rich text. That's not problem introduced with v1.0, it's a problem introduced at v6.0.
The problems I run into tend to be quite circumscribed deficiencies that are more like oversights than deep design flaws. I'd attribute that to the pressure to rapidly improve the API rather than the framework never have being thought through (In general, I find UIKit better thought out than AppKit).
Whether it was the official policy or not, I'd imagine that the UIKit team probably wanted UIKit to be an API... Wouldn't a private api that looked like that just be completely over-engineered?
>Whether it was the official policy or not, I'd imagine that the UIKit team probably wanted UIKit to be an API... Wouldn't a private api that looked like that just be completely over-engineered?
Yes probably, but API design is hard, and when the API is for something that big, it's even harder. My gut hypothesis is that Apple didn't initially put anyone with that particular expertise on the team because the people in charge thought HTML5 would be good enough. The people on the team, being UI developers, knew that that was silly and that the API would eventually need to be public, so they made a valiant effort to prepare for the inevitable.
I think the strongest argument for a markup language/translator for NSAttributedString is ease of localizing other languages. A translator can learn the basic markdown, and that can be passed along in a .strings file.
