With the release of SwiftUI, unless you have been paying attention to Swift Evolution, you might have been caught off guard by some of the new features introduced in Swift. In this post, I will start by showing a small snippet of code using SwiftUI and explain feature by feature, from my point of view. For a more in-depth explanation, please refer to each Swift proposal.

Certainly not the most exciting piece of code: the user inputs some text in the TextField and that same text is rendered in the Text, but it pacts quite a punch when it comes to using new Swift features!

#SE-NNN Function builders [link]

Leaving aside the controversial approach to this proposal, functions builders add syntactic sugar on how you can create an entity. From the example above, you might deduce that a VStack is created, but it's not apparent how this happens. In normal circumstances, one could have the VStack taking a variadic parameter as input when initialised:

This would work, but it definitely adds some unnecessary visual noise. In more complex examples, having the ability to remove the commas and the square brackets is definitely a plus.

With function builders you can also add conditional statements, like so:

I am yet to truly appreciate this feature, but I feel that as I get more experienced with SwiftUI it will grown on me. ☺️

#SE-244 Opaque Result Types [link]

Opaque result type refers to the odd some View. This feature was introduced in Swift 5.1. This allows API designers to hide implementation details from their consumers. It's the equivalent of saying:

I am going to return you "something" that conforms to the View protocol and you will decide what that "something" is.

It's important to notice that this is not the same as type erasure! The View type is known at compilation time and this can be witness in this example:

Because we are returning something different depending on the useVStacks condition, the compiler doesn't know the View type and you get the following error:

Function declares an opaque return type, but the return statements in its body do not have matching underlying types

#SE-258 Property Wrappers (previously Property Delegates)  [link]

Property wrappers are in my opinion is the most exciting feature of all three. It's exemplified by the $State in the snippet. In the latter, it adds the ability for the property to be bindable ( TextField($text) ), but also stores the value of said property in the View. I am not going to pretend I fully understand what's happening behind the scenes, but only what was shared to me at WWDC in the labs and how the property behaves from a consumer point of view.

It also allows you to add extra functionality to any property you want. This is quite powerful, because the sky is the limit when it comes to adding extra behaviours to your properties:

  1. Want to make your property lazy? ✅
  2. Want to store the value of your property in UserDefaults? ✅
  3. Want to delay the execution of a function by X amount of time? ✅
  4. Want to read the value of your property from a Dependency Manager container? ✅

I am not advising to add all this in your codebase, since some of these behaviours can be obscure to other people, but it's definitely something to consider. 😅

I recommend following Vincent Pradeilles. He has been sharing some pretty cool examples of the sort of stuff you can do with this feature.