Swift Stories

Welcome to issue 1!

Swift's structured concurrency introduced a powerful new mental model, enhancing app stability by catching data race issues at compile time. If you haven't adopted it yet, consider exploring it with this resource as a reference.

One intriguing aspect of structured concurrency is how its underlying concepts mirror ideas from Erlang's VM. In Swift, we have isolation domains, and in Erlang, we have processes. Both languages allow passing types safely across boundaries: Swift uses Sendable types, while Erlang relies on copying any type across processes. This shared principle of isolation underpins their ability to manage concurrent tasks effectively.

Unlike Erlang—which was designed with concurrency as a core principle—Apple had to integrate structured concurrency into an existing ecosystem of legacy code and patterns. This required reconciling the new mental model with an “unsafe” past while making the compiler aware of these scenarios. Despite this incremental approach, it’s fascinating to imagine how the app ecosystem could evolve if programming languages and their standard libraries fully embraced domains and message passing as the foundation for architecting code.*

Joe Armstrong, one of Erlang’s creators, introduced the concept of "Concurrency Oriented Programming Languages" (COPLs). He said:

In the real world, sequential activities are a rarity. As we walk down the street, we would be very surprised to find only one thing happening; we expect to encounter many simultaneous events.

If we did not have the ability to analyze and predict the outcome of many simultaneous events, we would live in great danger, and tasks like driving a car would be impossible. The fact that we can do things requiring processing massive amounts of parallel information suggests that we are equipped with perceptual mechanisms allowing us to intuitively understand concurrency without consciously thinking about it.

When it comes to computer programming, things suddenly become inverted. Programming a sequential chain of activities is viewed as the norm and is thought of as easy, whereas programming collections of concurrent activities is avoided as much as possible and generally perceived as difficult.

I believe this is due to the poor support provided for concurrency in virtually all conventional programming languages. The vast majority of programming languages are essentially sequential; any concurrency in the language is provided by the underlying operating system, not by the programming language.

Imagine, for a moment, if we modeled the business logic of our apps after concurrent actions instead of artificial constructs like interactors, controllers, and services—structures that don’t exist in the real world. This approach in Erlang enabled solutions that are simple by design. A similar shift in Swift could open doors to fault-tolerant, maintainable, and scalable apps, particularly as Swift expands into server environments.

Instead of prioritizing classes, structs, enums, and design patterns like repositories, builders, or adapters, we could focus on the core unit of isolation domains: actors. Actors could even supervise child actors, as in Erlang. For instance, an actor managing local data could have child actors responsible for individual data types. If a child actor crashes, the system could automatically restart it, introducing resilience. This actor-based mental model not only enhances data race safety but also enables fault tolerance by turning isolation domains into error boundaries.

Isolation domains can also revolutionize testing. If each end-to-end interaction with the app were modeled as an actor, you could test numerous interactions in parallel with minimal risk of flakiness in your test suite. This safe parallelism scales testing while maintaining reliability.

We believe these new mental models can radically improve app stability, maintainability, and testing scalability through safe parallelism. Adopting these ideas requires deeper familiarity and a willingness to think outside the box, but the building blocks for this transformation are already in place.

Food for thought