
Show HN: Attributed strings in Swift 4 - nirma
https://github.com/Nirma/Attributed
======
bsaul
?? 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)...

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

------
dreit1
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

------
mediumdeviation
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...](https://yuiblog.com/blog/2006/10/20/video-crockford-domtheory/)

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

~~~
dep_b
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.

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

~~~
dep_b
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.

