01 · INTRODUCTION
Swift Is Making Development Easier. We Want to Make It Understandable.
When Swift 6.2 was announced in September 2025, the Swift project described it as “a release aimed at making every Swift developer more productive”.
That ambition resonates with us. Making development easier is the reason we built 3DaysOfSwiftConcurrency.com, and the reason our work grew into the CFA AI Toolkit for iOS.
We wanted to answer two questions that kept coming up in our own development: what is happening in modern iOS, and what should a modern iOS app actually look like?
The answer changed how we organise our apps, how we work with AI, and what we believe developers need to learn next.
02 · OUR APPROACH
Easier tools still need an understandable model
Swift 6.2’s concurrency improvements included optional main-actor isolation by default, an opt-in change allowing nonisolated asynchronous functions to run in their caller’s execution context, and explicit concurrent execution with @concurrent. These changes aim to make everyday code easier to express and reason about.
For someone maintaining an iOS app, the practical questions remain: which part of the app owns this work? What happens while it waits? Who may change this state? What should happen if the user changes their mind?
Our programme exists to help developers answer those questions with confidence. We want you to read a feature and understand its behaviour, then make a change deliberately.
03 · OUR APPROACH
AI changed what we needed from our codebase
As we developed the training programme, it became clear that we needed to make better use of AI. We wanted help writing and changing code. Typing every line ourselves was no longer the workflow we were aiming for.
But accepting code we could not explain was equally unacceptable.
A generated feature can look convincing. Its names are sensible, its screen appears, and the ordinary path works. Understanding it requires more: we need to see where its decisions live, how it shares state, and what happens when operations overlap.
Our goal became simple: let AI help produce the implementation, while keeping the app understandable enough for us to direct and review it.
That required a structure we could discuss with a colleague or an AI model without reconstructing the whole application every time.
04 · OUR APPROACH
Legacy code made ownership difficult to see
In our older GCD-based code, following a feature could mean tracing callbacks, queue changes and state updates across several files. The feature’s intended behaviour was not always visible in one coherent path.
Changing a dispatch call into a Task would not, by itself, explain who owned the operation or what should happen when a second request arrived.
We needed to organise the application around recognisable features with clear responsibilities. We wanted to find the rules for search, reminders or saved items without confusing those rules with the details of how a screen displays them.
That need led us to Cooperative Feature Architecture and the CFA AI Toolkit for iOS.
05 · OUR APPROACH
Make each feature easy to find and discuss
CFA gives us an explicit structure for describing the application. AppModel brings its features together. Feature managers own shared domain state and business rules. Screen ViewModels handle presentation concerns, while provider and storage boundaries keep external details separate.
Those responsibilities give a conversation somewhere concrete to begin.
Instead of asking an AI model to “fix the app”, we can describe the feature, the behaviour that needs to change, and the owner of that behaviour. We can review whether the implementation follows those boundaries.
The toolkit gives us a repeatable way to communicate that structure when creating, changing and reviewing code. It also gives developers a shared picture they can discuss with one another.
Swift provides the concurrency model. CFA is our architectural approach to organising features within it. Swift does not require an app to adopt CFA.
06 · OUR APPROACH
Concurrency changes how we design the application
The more we learned about Swift Concurrency, the more significant the change became. Tasks, actor isolation and suspension affect the design of an entire feature, beyond the point where an operation starts.
Tasks describe asynchronous work. Executors schedule work for execution. Actor isolation controls access to isolated state. An await marks a possible suspension point, where other work may progress before the operation resumes.
That means a developer must consider what may change during a wait, how long an operation should remain relevant, and which part of the app owns its lifetime. Cancellation is cooperative; requesting it does not automatically make an obsolete result harmless.
These are architectural decisions. Swift’s language checks help enforce isolation rules, but they cannot choose the behaviour your users expect.
For us, adopting concurrency meant rethinking our app’s architecture. GCD remains part of existing applications and the wider platform; the opportunity is to make our own feature behaviour more explicit.
Explore the Swift language guide’s explanation of concurrency.
07 · OUR APPROACH
A search screen shows why these decisions matter
Imagine a reader searches for “actors”, then quickly changes the query to “cancellation”. Both requests begin, but the second one finishes first.
The screen correctly shows cancellation results. A moment later, the older actors response arrives.
Our intended behaviour is clear: the screen should continue showing results for the current query. The feature must check that a response still belongs to the active request before applying it. Cancelling the old request can help avoid wasted work, but the relevance check protects the result.
An actor can protect state access while the app still applies those responses in the wrong order. Preventing a data race and preserving the user’s latest intention are different responsibilities.
A useful test deliberately completes the second request before the first, then checks that the older result cannot replace the newer one.
This is the level of understanding we want developers to bring to AI-generated code: explain the expected behaviour, identify its owner, and check that it survives the difficult sequence.
08 · OUR APPROACH
What changed in our own workflow
Using this structure has made our development process more streamlined. In our own work, we have found AI-generated changes easier to follow and have spent less time untangling conflicting responsibilities.
We have also experienced fewer bugs and crashes in the apps we have been building, and more consistent behaviour for their users. Those are our observations from our own workflow, rather than a controlled benchmark or a guarantee for every project.
The practical improvement is that we can ask better questions. We can discuss the feature’s rules before generating its implementation, and review the resulting change against those same rules.
We still need tests, careful review and real use of the app. A clear structure makes that work easier to direct.
09 · OUR APPROACH
Learn by making decisions about real behaviour
We built 3DaysOfSwiftConcurrency.com around reading, reasoning and applying ideas. We did not want to create another sequence of videos for developers to watch and then struggle to translate into their own projects.
Our tutorials use explanations, diagrams and questions to help you form a mental picture of the running application. The training connects that understanding to practical app development.
The learning goal is to look at a feature and explain what happens: where the work begins, when it may suspend, which state it owns, and what happens when the user acts again.
Those skills remain valuable whether you write a particular implementation yourself, work alongside a colleague, or ask AI to help produce it.
10 · OUR APPROACH
Build your understanding alongside your tools
As you plan how to upskill for 2027, Swift Concurrency deserves a central place. It gives you a foundation for understanding asynchronous behaviour in modern Swift and for evaluating the code your tools produce.
Our aim is to make that foundation understandable, then give you an architectural approach you can use when building features.
You do not need to memorise every API before you begin. Start with tasks, suspension and isolation. Then follow those ideas through a feature whose behaviour you can explain.
Let your tools help you write the code. Build the understanding to decide what that code should do.
Start the free introduction to 3 Days of Swift Concurrency →