Show HN: Attributed strings in Swift 4 | Hacker News Reader

Show HN: Attributed strings in Swift 4

github.com

28 pointsnirma9 comments

?? why is this lib on front of HN ? i mean, it's a nice wrapper around a dictionnary, but NSAttributedString isn't really a hard part of the api, nor is it really awkard to use (especially since all the keys have been properly named in the latest releases)...

Right? Not mention the "crashes" mentioned in the repo will be caught as soon as you test it...

I do hate using attributed Strings, but tbh not enough to install an external dependency for it. Some syntactic sugar is not worth the overhead

I've had the pleasure of working with Swift for a few months last summer to develop some iOS prototypes. To borrow something Douglas Crockford said about JavaScript and the DOM in 2006[1], Swift is a pretty good language saddled with an awful API. I cannot believe that this is the stuff a multi-billion dollar company (Apple) is giving to developers to build the billion dollar "App economy".

As an example: To this day I have no idea what media formats are supported by AVAudioPlayer on iOS[2]. The documentation's links (Cmd+F "iOS Hardware and Software Audio Codecs") have been broken for so long that not even the Wayback Machine has a copy. And Googling for the same information only gives me Stack Overflow answers that references the same broken link. I suspect at this point not even Apple knows what formats their own audio framework is capable of playing.

[1]: https://yuiblog.com/blog/2006/10/20/video-crockford-domtheor...

[2]: https://developer.apple.com/documentation/avfoundation/avaud...

AVFoundation documentation/API's have absolutely nothing to do with the maturity of Swift's API. So much of Apple's internal API is still written in Objective-C (a problem and discussion for a different thread). But for your exact problem here: Check out the "Getting Supported Media Types" section.

https://developer.apple.com/documentation/avfoundation/avurl...

Sure, that link is broken, which isn't ideal, but the media formats supported are documented:

https://developer.apple.com/library/content/documentation/Mu...

In the same document there is a section titled "Playback using the AVAudioPlayer Class". Sure, this is in the Core Audio programming guide, but AVFoundation is just a ObjC layer on top of Core Audio that provides high level functions.

I think the API's for iOS aren't that awful but they've been designed in a different era for a different programming language. Untyped dictionaries as parameters for a method that actually will crash if you supply the wrong value for the wrong key is just against pretty much any philosophy that's behind Swift.

Also the current state of how ViewControllers interact with each other and the views just doesn't work too well with Swift. I tend to use coded views instead of Interface Builder just to get rid of those IBOutlets that only get set after init, forcing me to make them optional or crash-prone force unwrapped.

In Objective-C in conjunction with a clever type replacement for the root view it actually isn't so bad because everything is optional anyway.

It's impossible to overhaul the whole SDK without freaking out developers, but step by step things improve. A compile time error for outlet problems would be a good step.

Re: avoiding IB, https://github.com/SnapKit/SnapKit is a lifesaver, a lightweight DSL that nearly 1-to-1 wraps around AutoLayout APIs.

Tried it, didn't really like the syntax but Cartography has some performance problems so at the moment I'm back to hand rolled wrappers that are somewhat leaky but a lot less verbose and more readable:

    Constraint.space(imageView, .horizontally, to: textView, distance: 8)

I can imagine going back to SnapKit though. It really did what it should do.

Reply on news.ycombinator.com