Balraj Singh
SwiftUI is a new Toolkit introduced by Apple in WWDC 2019. As per Apple description:-
SwiftUI is an innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift. Build user interfaces for any Apple device using just one set of tools and APIs.
Today we are gonna understand
What is SwiftUI?
Why is it needed?
Finally, understand a sample code written in SwiftUI
So without delay let’s start our deep-dive into SwiftUI.
What is SwiftUI?
SwiftUI is a toolkit provided by Apple to build a user interface such as Custom Controls, Animations, Effects programmatically in a simple, declarative way. This help to reduce developer time to implement and makes it more readable hence easy to understand by anyone.
Why do we need it?
So why do we need to learn a new toolkit provided by Apple? What is so special about it? Let’s try to understand these problems now.
As a developer in the Apple platform, I believe we do need to write UI code programmatically now and then. This task is unavoidable yet so unpleasant. SwiftUI toolkit tries to solve all these problems by providing declarative APIs to create View, Animations and anything that one needs to perform to create a UI. Let’s see an example to get a better clarity:-
This tabular view clearly shows the difference in the level of abstraction and code simplification that SwiftUI toolkit provides. In the traditional way of writing UI code, one has to emphasize more on HOW part more than WHAT part of the task. With the declarative way of SwiftUI, **we don’t have to care about **HOW part.
Not only does it provide the advantage of writing UI in a declarative way. But also has a crazy new feature of supporting live preview of real-time changes made in the code.
Clearing seeing the advantages of using SwiftUI one may be tempted to use this new toolkit straightforward. But still, there are a lot of dark areas that we need to explore.
But still, there are a lot of dark areas that we need to explore.
Is SwiftUI, only an adapter layer over UIKit components to provide a declarative and simplified way of writing UI code?
Does it provide any performance benefits or loss?
When one shouldn’t use SwiftUI toolkit?
We will continue to explore more about SwiftUI and try to answer these questions now or later. But these are important questions to understand and make judicial decisions about SwiftUI usage.
Let’s deep-dive into SwiftUI code
For our understanding, we will take a small sample code written using SwiftUI.
This code creates a single view with 2 Labels in a vertical stack view with some font styling and color. Let's go through line by line and understand what it meant.
**Line 1–2: **These lines don’t do much but only imports SwiftUI and Playground support library.
Line 4: *This line creates a ContainerView struct which implements View protocol. View protocol is a type that represents a SwiftUI view. Let’s check out View protocol.
View protocol represents a piece of user interface. When creating a custom view one needs to implement this protocol. Also, implement the required **body* property to provide the content and behavior for your custom view.
Line 5: *This line implements *body *property to define the content of the main view. What is this new keyword **some*?
This is an opaque result type as introduced by SE-0244 and is available in Swift 5.1 with Xcode 11. This behaves like a “reverse generic”. In a traditional generic function, caller decides what types get bounded to callee’s generic arguments. But with opaque result type, the return type is chosen by the callee and comes back to the caller as abstracted.
Line 6: **This line creates an Object of Vertical StackView and returns the instance. This instance is then assigned as a value to **body property of the Container View.
We can clearly see that there is no return keyword used here. This is due to a new feature added in Swift5.1 **“Implicit returns from single-expression functions” **SE-0255. If a closure contains just a single expression, that expression is implicitly returned — the return keyword can be omitted.
Let’s see what all values do VStack view takes in its constructor.
VStack takes 2 arguments in its constructor the horizontal alignment of the content, the spacing between contents and the Content that needs to be added in VStack view. This Content *return *type is nothing but a custom view that implements View protocol of SwiftUI.
In our sample code, we take the default values of horizontal alignment and spacing. With that **Line 7–14 **provides the Content value for VStack that gets added as a subview.
**Line 7–14: **In these lines, we are creating 2 TextView and that gets added as a Content to VStack. But how is this happening? We have already discussed how a single expression doesn’t need to add return statements, but line 7–14 doesn’t consist of a single expression and if we add more Views that will also get added as Content within the VStack View.
This is the result of yet another new feature introduced in SwiftUI — **function builders. **There is also a parallel pitch made to introduce this feature in Swift language also here.
Function builder feature which allows certain functions (specially-annotated, often via context) to implicitly build up a value from a sequence of components. The basic idea is that the results of the function’s statements are collected using a builder type. For example:-
Similarly VStack can do this because it has the ViewBuilder function builder in its signature:
**@ViewBuilder *keyword transforms into a ViewBuilder struct which has the definition of how to parse the given expression. Hence when we write expressions for creating Views within *VStack** the compiler runs its magic with the help of ViewBuilder converts that to **TupleView<(View, View)>. **Hence we can see that the type of View that VStack holds our sample code is VStack>.
This also means that there is a limitation to the number of views that you can add to VStack or HStack. By digging more into the code I found that you can have at most 10 views inside VStack or HStack. Anything beyond this is not supported currently.
So I hope now our sample code is making some sense.
Conclusion
SwiftUI not only brings a declarative way of writing UI code but also shows us the future of swift as a language. Features like function builder, **Implicit returns from single-expression functions, opaque result type **are all steps to building a new world of writing declarative code in Swift. Let's all embrace these new changes and start exploring this new world.
