Slash: A markup language for styling text on iOS
github.com
github.com
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.
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.
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?
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.