Building UIs for iOS applications means to layout, style and react to events. Even though UIKit provides most of what we need, there are still areas where the experience can be improved. For example, the indirection enforced by the pervasive use of delegates and selectors forces your code to be split apart. It would also be nice if we could have access to more of Swift’s expressive power such as value types and generics when working with UIKit.
With the introduction of the Flow framework we presented a fundamental programming model for working with UI events. We followed up with the Presentation framework for a more formalized way of presenting view controllers from model to result. …
View controllers play a central role when building iOS applications. However, building, managing and presenting view controllers is not always straightforward. There are many questions that need to be answered, and many alternatives to consider:
In this article, we will explain what asynchronous operations are, why they are useful, and how their APIs are typically designed. Specifically, we will look at an API for performing network requests. Step by step, we will improve this API, first by introducing the
Result<T> type, and later on, by abstracting the asynchronous operation itself, by deriving the
Future<T> type. We will also show how these two types could be implemented and extended with useful operations. In the end, this will lead to code that is more composable, easier to reason about as well as to maintain.
When building applications interacting with a user, a goal is to keep the application responsive at all time. It is thus important to not perform long-running operations that will block the UI. This is one reason why many APIs used in UI intensive applications are asynchronous. Being asynchronous means that the caller will not block while executing an operation using the API, but instead, the API will call the user back when the result is available. …
When working with UI frameworks, it is very common with APIs that want to notify the user of changes of different kinds. In Apple frameworks, these are typically expressed through the use of notifications, target/action, delegates or registration of callback closures.
In the article “Deriving Signals” those different APIs were unified by the introduction of the
Signal type. This article will further explore the utility of signals and how they can become even more convenient to work with.
We start off by extending
Signal with more useful transforms. Then
UIControl is extended to signal UI events such as text field changes. …
In this article, we will explore three abstractions that are useful building blocks in asynchronous event handling. As a use case, we will build an API for registering callbacks to get notified of events. Working with callbacks might sound trivial at first. After all, it is just the passing of a closure to be called back on event updates. But as it turns out, we will run into several challenges to come up with an API design that is both robust and flexible.
It all starts out with trying to find a solution how to deregister our callbacks, a lifetime management problem which leads us to the
Disposable protocol. After that, we address the repetitive work of callbacks book-keeping, leading us to the reusable
Callbacker type. Finally, we investigate how to make our callbacks even more composable and stand-alone by bringing it all together into a basic implementation of a
Signal type. …
Today we are proud to announce the open sourcing of Flow, a Swift framework for building and maintaining complex asynchronous flows. Flow is modern, lightweight and composable, allowing you to write code that is more robust and easier to reason about. It has been field-tested and has matured over the course of many years while being extensively used in iZettle’s point of sale app to solve real problems.
If you ever wondered what this thing about reactive programming is, now is the time to give it a try. …
There have been many attempts to build Swift libraries for both parsing and generating JSON. The reason is probably that there is no obvious Swift solution and JSON parsing is something most developers have to frequently confront. Swift 4 introduced
Codable with the promise to solve this once and for all, and for many scenarios, it is just magic. But as soon as your models start to diverge from the simple one-to-one mapping between model and JSON, you have to implement everything yourself using a quite verbose API. Swift also currently lacks APIs for building and parsing JSON on the fly, not going through model objects, which is common when building and parsing network requests. …