Last week I saw that the community tries to move UIKit development patterns to SwiftUI. But I’m sure that the best way to write efficient SwiftUI is to forget everything about UIKit and entirely change your mindset in terms of User Interface development. This week we will learn the main differences between UIKit and SwiftUI development.
One thing which I really enjoy about SwiftUI is the fact that SwiftUI has a lot of stuff ready to use out of the box. In order to build your app, all you need to do is composing the building blocks provided by SwiftUI into a fully functional application. This week we will talk about Gradient, which is just another type of View in SwiftUI.
One of my favorite design patterns in UIKit development was a Delegate pattern. Delegate pattern is very straightforward, and everybody knows how to use it. In the Functional Programming world, we usually replace delegates with closures. This week we will learn how to use closures to make SwiftUI views composable and decoupled.
SwiftUI is a declarative framework for building User Interfaces on Apple platforms. The keyword here is declarative. Declarative means that you need to declare what you want to achieve, and the framework takes care of it. Framework knows the best way to render the User Interface, which you declare.
This week we will talk about reusing SwiftUI views between Apple platforms. We will learn how to run the same views both on iOS, watchOS and macOS without any changes. To make it possible, all we need is an understanding of the view decomposition principle.
This week I want to talk about another crucial feature of any app, which is Localization. Every user expects that your app correctly uses environment features like the right-to-left layout or uses system locale to format dates or currencies. Another vital thing here is translations, and this week, we will learn which tools SwiftUI provides to add in our apps as many languages as we can.
This week I want to talk to you about Dynamic Type support in SwiftUI. I think there is no way to create an excellent user experience without Dynamic Type support in your apps. SwiftUI provides Dynamic Type out of the box for any text representation and simplifies our job. But we still need to do some work, so let’s talk about it.
This week I want to continue the topic of using a Redux-like state container in SwiftUI. I’m delighted with the new approach and already finished the refactoring of the NapBot app in this way. That’s why today I want to share with you how I use Container Views with a state container similar to Redux.
Last week we talked about building a state container similar to Redux in SwiftUI. Redux provides a single source of truth, which eliminates tons of bugs produced by multiple states across the app. This week we will talk about best practices in building Redux-based apps which allows us to keep our codebase simple and clean.
This week we will talk about building a state container similar to Redux and The Elm Architecture that provides a single source of truth for your app. A single state for the whole app makes it easier to debug and inspect. Single source of truth eliminates tons of bugs produced by creating multiple states across the app.