THE 2027 FIELD GUIDE · 15 STEPS · 4 STAGES
iOS Developer: Swift Concurrency Guide 2027
Understand how your app runs. Build cooperative features. Work confidently with AI.
Build a clear mental model of how your app runs, then use that model to design, build and explain cooperative features with Swift Concurrency. This guide gives existing iOS developers a practical curriculum: from threads and memory to a working app, reliable shared state and AI-assisted development.
If you already know how to build a screen, the next step is understanding everything happening around it. A request waits. A user taps again. Another feature changes shared data. Your architecture needs to make those behaviours understandable.
🎯 Your outcome: an Xcode project you can explain from a button press through its feature logic, asynchronous work and state updates—and enough understanding to direct the next change yourself.
The path below follows the progression behind 3 Days of Swift Concurrency: foundations, the Next Launch app, Reminders, multiple providers, persistence and feature development with the CFA AI Toolkit. Use the Core and Advanced glossaries as references throughout.
This is a plan for learning in 2027 using established capabilities. Move forward when you can explain and demonstrate each checkpoint; the programme’s three-day structure does not require everyone to learn at the same pace.
STAGE 01 / 04
Understand how your app runs
Threads · Memory · Execution paths
STEP 01 / 15
1. Distinguish concurrency from parallelism
Begin with a timeline. Concurrency allows several activities to make progress during the same period. Parallelism means work is actually executing at the same time.
A single core can alternate between threads. Multiple cores can execute work simultaneously. A network request can also remain in progress while your app performs other work, without the waiting request continuously occupying a CPU.
YOUR PRACTICE
draw two downloads and an interface update. Mark which parts are executing and which are waiting.
READY TO MOVE ON WHEN…
explain why two operations can overlap without two pieces of your Swift code executing at the same instant.
STEP 02 / 15
2. Build a mental model of a thread
Think of a thread as an execution context the operating system can schedule. It has register state, including an instruction position, and a stack used by ordinary function calls. A thread is different from the CPU core that executes it.
When a thread stops running, the system can preserve its execution state and later resume it. Threads in one process share that process’s virtual address space.
YOUR PRACTICE
pause a small app in Xcode and inspect its threads and call stacks. Follow one stack from a function you recognise to its callers.
READY TO MOVE ON WHEN…
explain how several threads can belong to one app even when the device has fewer cores than runnable threads.
Apple’s background reference on threads and their resources.
STEP 03 / 15
3. Understand stack, heap and memory costs
Learn the stack as storage associated with active synchronous calls, and the heap as dynamically allocated storage whose lifetime can extend beyond one call. This is a starting model: Swift’s compiler can optimise storage, and a variable’s syntax alone does not tell you where every byte lives.
Heap allocation and releasing storage have costs. Access performance also depends on locality, caches, indirection and synchronisation. Sharing frequently modified data between cores can introduce contention and cache-coherence work.
Reading heap data from another thread is not automatically slower. Distinguish allocating an object, accessing its contents and coordinating shared mutations. Measure the operation you are investigating.
YOUR PRACTICE
inspect allocations while loading and releasing a list. Identify which objects need to survive the function that created them.
READY TO MOVE ON WHEN…
explain why “struct means stack, class means slow” is too crude to guide performance decisions.
Swift.org’s allocation guide explains the underlying costs; its profiling examples target servers.
STEP 04 / 15
4. Follow the binary into a running process
Your Swift source is compiled into machine code and linked into an executable. An iOS app bundle also contains resources and may contain embedded frameworks. Apple platforms use the Mach-O executable format, with segments representing code and data.
At launch, the system maps executable code and supporting libraries into the process’s virtual address space. This is a simplified picture, not a claim that every byte is immediately copied into physical memory.
An execution path is the sequence of instructions taken through calls, branches and returns. Each thread has its own current execution state; two threads can execute the same function with different inputs.
YOUR PRACTICE
put a breakpoint in a button handler, step into a function and inspect the call stack. Relate the source line to the executing instructions.
READY TO MOVE ON WHEN…
explain the difference between code stored in the app, a running process and a thread progressing through that code.
Apple’s Mach-O overview provides background on executable layout.
STEP 05 / 15
5. Revisit shared data with your new memory model
Now imagine two execution paths reaching the same mutable object. Having separate thread stacks does not give each thread a private copy of that object. Both can hold references to shared storage.
Draw a reminder collection with two callers: one adds a reminder while another asks for the list. Decide who owns the collection and how access is coordinated.
YOUR PRACTICE
mark every place that can mutate one collection in an existing app. Separate shared state from values returned as snapshots.
READY TO MOVE ON WHEN…
identify the owner and access rules for that state. “Both functions work individually” is not enough to establish that their overlapping use is correct.
STAGE 02 / 04
Build a modern architectural model
Tasks · Architecture · Cooperative features
STEP 06 / 15
6. Connect threads to Swift’s tasks and executors
Introduce the next layer: Tasks represent asynchronous work, while executors schedule jobs for execution. A task can suspend and later resume; it does not own a dedicated thread. Actor isolation governs access to state rather than granting each actor its own thread.
The runtime manages Swift task execution alongside the operating system, the main run loop and other frameworks. An iOS app does not move entirely onto a replacement operating-system scheduler when you add async.
YOUR PRACTICE
draw two levels: tasks and executors above, threads and CPU cores below. Follow an operation from MainActor to a provider actor and back.
READY TO MOVE ON WHEN…
explain why suspension and blocking have different effects on the thread’s ability to perform other work.
Apple’s Swift Concurrency: Behind the Scenes explains this runtime model.
STEP 07 / 15
7. Create a mental template for modern iOS architecture
Use those foundations to draw an application you can reason about. Our programme uses Cooperative Feature Architecture: Views display state, screen ViewModels manage presentation, feature managers own shared domain state and rules, and provider or storage boundaries handle external details. AppModel assembles the features.
For each operation, add its owner, isolation boundary and lifetime to your drawing. Decide where a screen’s local draft belongs and where state shared across screens belongs.
Concurrency becomes an architectural concern: it shapes ownership, dependencies and behaviour while work waits. Swift provides the language and execution model; CFA supplies one concrete architectural approach.
READY TO MOVE ON WHEN…
point to where a new feature belongs before asking AI to implement it.
STEP 08 / 15
8. Build the first cooperative app
Follow Day 1’s Next Launch project. Begin with one launch-data provider, one feature manager and a screen that displays upcoming launches. Open the starting Xcode project, then follow the build-it-yourself sequence.
Keep the first version small enough to explain. Trace a refresh from the View through its ViewModel and feature manager to the API, then back to visible state.
YOUR PRACTICE
change a small display requirement and predict which files should change. Then compare your prediction with the implementation.
READY TO MOVE ON WHEN…
demonstrate a working refresh and explain who owns its data and loading state. A successful build is the beginning of this check.
STEP 09 / 15
9. Add a second feature that cooperates with the first
Use Day 2’s Reminders feature to extend the same app. Launch information and reminders have different responsibilities, yet they need to cooperate when a reader chooses a launch or its scheduled date changes.
Follow the reminder manager, notification boundary and dedicated screen ViewModel. Connect the features through the shared model rather than making a screen construct the application’s dependencies.
YOUR PRACTICE
create a reminder, change the launch date in a controlled scenario and follow the resulting update.
READY TO MOVE ON WHEN…
explain which feature owns the reminder and why the launch screen does not need to own the notification implementation.
STAGE 03 / 04
Make concurrent features reliable
Syntax · Cancellation · Failure and recovery
STEP 10 / 15
10. Read the code and explain what can overlap
Read your implementation aloud as a sequence of events. Name the operation, its isolation and the points where it waits. Separate the ordering required by the code from the scheduling chosen at runtime.
Ask whether two provider requests are independent, whether they are started before either result is awaited, and whether their processing shares a serial executor. Overlapping network waits do not prove simultaneous CPU execution.
YOUR PRACTICE
sketch a timeline for a refresh and a reminder action. Label the places where you need further evidence from the code or profiling.
READY TO MOVE ON WHEN…
explain possible concurrency without claiming guaranteed parallel execution simply because two Tasks exist.
STEP 11 / 15
11. Build a working vocabulary of concurrency syntax
Keep the programme’s Core and Advanced glossaries beside your project. Learn each term through a decision in your own code.
- async and await: asynchronous functions and possible suspension points.
- Task: starting and managing task work; identify its owner and lifetime.
- actor, MainActor and Sendable: isolation and safe transfer across concurrency boundaries.
- async let: structured child tasks for a known set of independent operations.
- Task groups: structured child work when the number of operations varies.
- AsyncSequence and for await: consuming values that arrive over time. The loop body is sequential unless you explicitly introduce additional concurrent work.
- Cancellation and errors: how unfinished work stops cooperating or reports failure.
YOUR PRACTICE
annotate a feature using these terms, then remove the annotations and explain it again. Check project isolation settings when comparing examples from different Swift versions.
READY TO MOVE ON WHEN…
choose between sequential awaits, async let and a task group based on dependencies and lifetime.
STEP 12 / 15
12. Decide what repeated actions should do
Return to the Refresh button. What should happen when it is pressed twice? Day 1 explores cancelling previous work and sharing an operation already in progress. Neither policy is right for every feature.
For a search field, the latest query may take priority. If query B finishes before the older query A, check that A is still relevant before allowing it to update the screen. Cooperative cancellation alone is not that check.
Day 2’s actor mechanics add another question: what might have changed while an isolated method was suspended? Recheck the assumptions that matter when execution resumes.
YOUR PRACTICE
deliberately complete B before A with a controllable test provider and verify that A cannot overwrite B. Also test a failed or cancelled operation.
READY TO MOVE ON WHEN…
state the policy before implementing it and show evidence that the difficult ordering follows it.
STEP 13 / 15
13. Extend the app with multiple providers and saved data
Follow Day 3’s progression: add independent launch providers, handle partial failure, retain useful data between launches and share a colour theme across screens.
These changes make architecture tangible. The feature coordinates providers; presentation explains incomplete results; the storage boundary owns persistence details. A provider failure should follow a deliberate policy rather than accidentally erase everything useful.
YOUR PRACTICE
make one provider fail, then make all providers fail after a successful refresh. Relaunch with cached data and inspect how the screen communicates its state.
READY TO MOVE ON WHEN…
show useful behaviour during failure and recovery, and explain which owner makes each decision.
STAGE 04 / 04
Direct AI and modernise existing apps
Code review · Feature ownership · Migration
STEP 14 / 15
14. Use AI to extend a project you understand
Bring in the CFA AI Toolkit for iOS and the programme’s AI guides. First ask the assistant to explain the existing app: its features, state owners, boundaries and task lifetimes. Compare that explanation with the source.
Then request a focused change, such as the search or favourites work in Day 3. Give the assistant observable requirements and the behaviour that must remain intact.
“Explain the existing feature path first. Propose the smallest change for this requirement, identify the state and task owners, preserve the other features, and demonstrate the important success and failure cases.”
YOUR PRACTICE
review the changed files and run the feature yourself. Ask why each new type or responsibility is needed.
READY TO MOVE ON WHEN…
you can explain the generated change to another developer and challenge it when its behaviour differs from your request.
STEP 15 / 15
15. Apply the curriculum to your existing iOS app
Choose one legacy feature whose behaviour you know. Record its current success, failure and repeated-action rules. Map its callbacks, queues and shared state, then migrate it in a controlled step.
Use your new architecture as a reference while preserving the product’s behaviour. Keep the migration small enough to review and test. You can modernise incrementally while existing GCD-based code continues to serve other parts of the app.
YOUR PRACTICE
compare the original and revised feature under slow responses, repeated taps and failures. Include responsiveness and accessibility in the review.
READY TO MOVE ON WHEN…
explain both the architectural improvement and the evidence that the feature still behaves correctly.
YOUR NEXT CHAPTER
Use the programme as your learning route
- Free introduction: begin building the conceptual foundation and identify the terms you need to revisit.
- Day 1 — Next Launch: establish the project structure, follow a button press and choose repeated-request behaviour.
- Day 2 — Mechanics and Reminders: connect actors, jobs, executors and threads to a second cooperating feature.
- Day 3 — Extend the app: coordinate providers, handle failure, retain data, share a theme and direct AI-assisted changes.
- Core and Advanced glossaries: revisit terminology as you encounter it in working code.
- CFA AI Toolkit and AI guides: carry the architectural approach into further feature work.
Your progress is the collection of things you can now explain and demonstrate: a memory model, an architecture drawing, a working app, deliberate concurrency policies and a change you can defend in review.
That is a practical way to upskill for 2027: understand the running app, build its features deliberately, and use AI from a position of understanding.