Book Image

SwiftUI Projects

By : Craig Clayton
Book Image

SwiftUI Projects

By: Craig Clayton

Overview of this book

Released by Apple during WWDC 2019, SwiftUI provides an innovative and exceptionally simple way to build user interfaces for all Apple platforms with the power of Swift. This practical guide involves six real-world projects built from scratch, with two projects each for iPhone, iPad, and watchOS, built using Swift programming and Xcode. Starting with the basics of SwiftUI, you’ll gradually delve into building these projects. You’ll learn the fundamental concepts of SwiftUI by working with views, layouts, and dynamic types. This SwiftUI book will also help you get hands-on with declarative programming for building apps that can run on multiple platforms. Throughout the book, you’ll work on a chart app (watchOS), NBA draft app (watchOS), financial app (iPhone), Tesla form app (iPhone), sports news app (iPad), and shoe point-of-sale system (iPad), which will enable you to understand the core elements of a SwiftUI project. By the end of the book, you’ll have built fully functional projects for multiple platforms and gained the knowledge required to become a professional SwiftUI developer.
Table of Contents (13 chapters)

Understanding State and Binding

State is a topic that I wanted to cover once you had some understanding of SwiftUI. Using State in SwiftUI simplifies our apps because we will now have one source of truth. When using State, persistent storage is created by SwiftUI for each of our views. Here is an example of a State property:

@State private var isDriverEnabled: Bool = false

In this book, you have seen something similar to this, but let's take the time to break it down thoroughly. By adding @State, we tell the system that the isDriverEnabled variable changes over time, and that views will depend on this value. Changes to @State-wrapped properties initiate a re-rendering of the view when the values are updated. Every change is dispersed to all of the views of the children.

If you have two views inside your main view, which also needs to react to a change, these views will not use the @State property. The topmost view always owns the State-wrapped properties. All of the...