The language definitely feels like it has matured as the change from 3.0 to 4.0 was pretty much painless. The big issue with programming in Swift is no longer swift itself but the libraries around it. A lot of the API's you use in day to day Cocoa programming are based on Objective-C and often stringly typed and not very compile safe.
For example NSNotificationCenter, setting attributed strings, core data or fetching resources. Also the whole MVC ViewController lifecycle is full of optionals. A lot of people abandon using Storyboards just to have ViewControllers that have everything set up compile safe, don't use prepareForSegue to pass in variables and so on. But that means doing everything in code, which is inefficient for complicated one-off layouts.
Attributed Strings got better type information in Swift 4 (it got what Notification keys got in Swift 3), but like notifications it's an open-ended API so I don't know what else you can do...
You can't use an enum for the keys because it supports custom attributes (at least you can't without exposing a `.custom(name: String)` case, which would defeat the purpose). And the values can be different types (enums for underline styles, URLs for links, [NS|UI]Color for foreground colors, etc.). I think the `NSAttributedStringKey` box type is a good compromise.
Maybe I'm biased (the Cocoa text system is one of my favorite APIs, and NSAttributedString is at the top), but I'm really happy with the state of attributed strings in Swift 4 myself.
True, but that's exactly the kind of change to the API required to make it more compile-safe. I still managed to crash this API by not providing a .rawValue somewhere. I don't think applications need to crash on key-value errors.
An enum wouldn't be so bad if it also would use the associated value. Would make it impossible to set the wrong value at least.
Ahh right, NSUnderlineStyle... I totally thought that was improved in Swift 4, what a bummer. I have some unit tests in my apps that make sure I'm setting the .rawValue instead of the enum case itself, because that one does suck. I'm gonna file a bug.
Swift also supports associated values with enum cases, so you could do something like this[0] and get type-safety. Now you could only associate a URL type with a link attribute, or an NSColor type with a foregroundColor attribute, etc.
However, you can't (at least currently) add new cases to someone else's enum (the way you can add methods). So if I decided I wanted my own custom text attributes (which isn't uncommon), we're back to type-unsafe land. We'd need the original enum to have an extra attribute case, like this[1].
Storyboards kind of suck for any team bigger than 1 as far as I’m concerned. They also lock you into a visual binding style development pattern the doesn’t scale as your app grows. Don’t get me wrong, they’re great for fast prototyping or teaching someone how to write code as it helps with a ton of boilerplate.
I think that's a bit overstated but it really depends what kind of application you're writing. I have an accounting app I maintain alone where I almost completely abandoned storyboards because a lot of screens had similar elements and it was very important to have all data reliably passed around. Also helped with consistency and maintainability. On the other hand I'm doing a new app with three people now where we use storyboards because every screen is vastly different.
The following things should be improved to make storyboards more useful in teams:
* No more bullshit changes of 0.5px just by looking at the storyboard alone
* Compile time check for connected outlets and actions, allowing to set them without the ! or ?
* Constructable view controllers that always require you to init them in some kind of way, so you don't end up with optionals everywhere
* Reusable constants for colors, sizes etcetera. I want to simply state cellSpacing as a value for the constant of a constraint where cellSpacing is something I can change in one place.
* Reusable components / controls, like .xibs but immediately visible
For example NSNotificationCenter, setting attributed strings, core data or fetching resources. Also the whole MVC ViewController lifecycle is full of optionals. A lot of people abandon using Storyboards just to have ViewControllers that have everything set up compile safe, don't use prepareForSegue to pass in variables and so on. But that means doing everything in code, which is inefficient for complicated one-off layouts.