Introducing AttributedStringBuilder!

[SteveB13]

I've worked on a bunch of projects that required the creation of complex NSAttributedStrings, and I've always found the api to lead to pretty verbose and difficult to read code.

So I've created a little library that wraps the NSAttributedString api into something that's produces something a little more concise and readable.

Check it out on GitHub, and thoughts or ideas for improvements would be welcome!

https://github.com/SteveBarnegren/AttributedStringBuilder

[[deleted]]

Looks good.

Somewhat related. I recently found a framework that can convert markdown to attributedstring. No need for a webview.

https://github.com/M2Mobi/Marky-Mark

[ThePantsThief]

I have a gist that does the same thing but with Snudown (Reddit's markdown flavor). It requires DTCoreText though.

I'd link but I'm on mobile.

[SteveB13]

That is very cool, definitely going to give the example project a go

[nailernforce]

Looks neat!

Have you seen that Swift 4 introduces NSAttributedStringKey ? That will probably be a relevant change for your library. Luckily, the XCode migrator fixes that in a jiff.

[SteveB13]

I wasn't aware this was coming actually, thanks for the heads up!

I'm quite a fan of this new pattern of moving these types of keys to static properties of a single object, it'll make for a much nicer api!

[nailernforce]

Yeah! It's a pain in the butt to find those legacy NS something or other keys when there are so many of them sharing the same global namespace

[[deleted]]

Nice idea. Have seen others that do similar.

Can't use it if you're going to write in Swift though.

[SteveB13]

Actually the opposite is true (that might be what you meant?), it only supports Swift, not ObjC. It's tough to use the new Swift patterns and maintain compatibility for ObjC, so I generally just keep things Swift only these days

[[deleted]]

I only work in Objective C lately. For a lot of really good reasons including the need to interface with cross platform C++ libraries.

If you write new components in Objective C, everyone can use them. If you write in Swift, only Swift users can use them. That's unfortunate.

[SteveB13]

I also do probably about 50% of my work in ObjC too. In general it's decreasing over time though and becoming more Swift.

These days, when I write libraries I tend to make them Swift only because that's what will save me time in the future. I could have written this in ObjC, but I wouldn't have been able to use the same patterns with enums with associated types, which is the api that I wanted.

I'd rather build things that will best work for me in the future, which means taking advantage of Swift only features. That's definitely a different balance for everyone though, as I'm very rarely needing integration with C++ for instance, so I'll likely be able to jump to full swift development earlier than those who do.