This week we will continue exploring the new Navigation API in SwiftUI. One of the benefits of the new data-driven Navigation API is the programmatic navigation with deep-linking possibilities. Let’s dive into the new API by learning how to build programmatic deep navigation flows.
SwiftUI is the declarative data-driven framework allowing us to build complex user interfaces by defining the data rendering on the screen. Navigation was the main pain point of the framework from the very first day. Fortunately, things have changed since WWDC 22, and SwiftUI provides the new data-driven Navigation API. This week we will learn how to use the new Navigation API to build complex user flows.
WWDC22 brings tons of new features to SwiftUI and makes it a full-featured UI framework that we can use daily. Unfortunately, most of the new features are available on iOS 16 and macOS 13. This post will cover the most significant additions and changes to the SwiftUI framework.
SwiftUI provides us with a rich set of view modifiers to manipulate the accessibility tree of views. I covered many of them, and you can find them in the blog’s dedicated Accessibility category. This week we will talk about the accessibilityChildren view modifier and how we can benefit from it.
TimelineView is a SwiftUI view type that updates its body according to a provided schedule. We used to see SwiftUI views updating its body whenever the data it presents changes. TimelineView doesn’t follow this rule and allows us to build a super-custom schedule to update its content in a precise way. We will learn how to use TimelineView to create time-based views this week.
The new Swift Concurrency feature doesn’t only bring new opportunities for writing safer and more maintainable async code but also changes the way we handle errors. I didn’t use throw-catch keywords too much in my legacy code because usually, I had a completion callback with the Result type handled by the switch operator. This week we will talk about modeling error types and how we will address them in Swift with throw-catch keywords.
The Unified Logging System is a great way to build a proper logging system allowing you to understand different exceptional cases happening in your app. But it is not limited only to logging. It also provides a way to measure various events in your app. This week, we will learn how to use the Unified Logging System to measure app performance.
We discussed building a proper logging system instead of using the print function in the previous post. Apple provides us a framework to utilize its logging system backed by on-disk persistence. This week we will talk about exporting logs from the user devices by leveraging the power of the Unified Logging System.
We encounter bugs that are very hard to catch in the debugger from time to time. For example, it might occur only after a few days of app usage. In this case, running an app in a simulator and testing a feature doesn’t make sense. We need to understand what the user has done in the application and how it responds to user actions in this situation. Logging is an excellent technique to track and understand user actions through the app. This week we will learn how to implement proper logging functionality in our apps.
Last week we talked about the basics of CloudKit. We learned how to save and fetch data from the storage in the cloud and how to sync the data between devices. This week I want to cover the only reason why I have chosen CloudKit instead of Firebase, and it is data sharing between users.