# ConcurrencyRecipes, a cookbook that names its hazards before its recipes > ConcurrencyRecipes collects practical solutions to Swift Concurrency problems, and it does something most cookbooks skip: it fixes a shared vocabulary of eight hazards first, so the recipes can refer to timing, ordering, reentrancy and the rest in the same words. The repository is also candid that its code predates Swift 6.0. **dimasusername/ConcurrencyRecipes** — Practical solutions to problems with Swift Concurrency - Repository: https://github.com/dimasusername/ConcurrencyRecipes - Stars: 1,325 · Forks: 45 - Language: Swift - License: BSD-3-Clause - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/dimasusername-concurrencyrecipes ## Written by someone learning in public ConcurrencyRecipes is described plainly as practical solutions to problems with Swift Concurrency, and the framing sentence explains why the repository exists: Swift Concurrency can be really hard to use, and it seemed handy to document and share the solutions and hazards you meet along the way. What makes the README worth reading is the disclaimer that follows. The author says they are absolutely not saying this is comprehensive, or that the solutions presented are great, and adds that they are learning too. Contributions are invited, especially for problems. That is an unusual opening for a technical reference, and it sets the terms of everything in the repository: these are field notes from one developer, offered in the hope that they save somebody else an afternoon. The repository has changed hands. It was originally created by @mattmassicotte and is now maintained by @dimasusername, and the current maintainer has added a warning that matters for anyone reading the code, which we will come back to. The change of maintainer is itself a signal about the state of the project: the original author has moved on, the material remains, and someone else is keeping the lights on. For a reader, the practical effect is that this is a document to consult when you have a problem, not a specification to follow. That is a perfectly good use for it, and it is a different use from a framework or a library. ## Eight hazards, defined before any recipe After the table of contents, the README defines the vocabulary the recipes use. That ordering is the design decision of the repository, and it is the part worth borrowing even if you never open a single recipe. Timing is defined as more than one option being available, which can affect when events actually occur. Ordering is about unstructured tasks, where ordering is up to the caller, with the advice to think carefully about dependencies, multiple invocations and cancellation. Lack of caller control says that definitions always control the actor context, that this differs from other threading models, and that you cannot alter definitions you do not control. Sendability covers types that cross isolation domains, which is not always easy and, for types you do not control, not possible. Blocking notes that Swift concurrency uses a fixed-size thread pool, so tying up background threads can lead to lag and even deadlock. Availability reflects that concurrency is evolving rapidly and some APIs require the latest SDK. The last two are the ones people argue about. Async virality is the observation that making a function async affects all its callsites, and that this can result in a large number of changes, each of which could itself affect subsequent callsites. Actor reentrancy is the statement that more than one thread can enter an actor's async methods, and that an actor's state can change across awaits. A shared glossary is not a documentation nicety. Swift's own terminology has been shifting with each language version, and a recipe that says it is about ordering means something quite different from one that says it is about timing. Naming the eight hazards once, in one place, is what lets seven separate documents by two authors stay consistent. ## Seven recipe files, from async context to SwiftUI The table of contents lists seven markdown documents under Recipes/, and the names indicate the ground they cover. Creating an Async Context is the first, which is the right order: before you can talk about actors, isolation or task groups, you have to know how to get into an async context at all, and that is a problem with its own set of answers depending on where you are calling from. Using Protocols covers how protocols behave when they cross into concurrent code, which is where a Sendable requirement or an actor-isolated method turns into a design question rather than a syntax question. Isolation is the core topic, and it is the one the hazard definitions are built around, with lack of caller control and actor reentrancy both being isolation problems in disguise. Structured Concurrency follows, covering task groups, child tasks and cancellation. SwiftUI is the platform-specific chapter, and in a framework whose view model is defined by Swift's own concurrency rules, that chapter carries weight beyond the app it is written for. The repository layout backs this up. Recipes/ sits at the root next to Package.swift, Sources/ and Tests/, so the documents are first-class artefacts of a Swift package rather than a wiki page, and the Tests/ directory indicates that the examples are at least partly executable. What the README does not do is summarise the contents of each recipe, so a reader browsing for a specific problem has to open the files. That is a fair trade for a cookbook whose value is in the detail, and the hazard list in the README is the map that a newcomer should read first. ## The two chapters about code you did not write The last two recipes are the hardest and the most useful, and the hazard list explains why. Using Libraries not Designed for Concurrency is about the boundary of the type system, and the Sendability hazard is written with a deliberate edge to it: types that cross isolation domains must be sendable, and this is not always easy and, for types you do not control, not possible. That is a blunt statement of a real constraint. A great deal of code in a modern app is a dependency you did not write, and if that code hands you a class across an isolation boundary, no amount of care on your side makes the boundary safe. The recipe is about what to do when the answer is not in your hands. Interoperability is the second, and it sits alongside a hazard that is easy to skim past. Availability notes that concurrency is evolving rapidly and some APIs require the latest SDK, which in practice means a recipe written against one SDK may not compile against another, and that the availability annotations around concurrency APIs are a real constraint on how far back you can target. There is a third theme running through both chapters, and it is the one that makes them different from the rest of the book. Async virality explains why changing an existing function to async cascades outward, and ordering explains that with unstructured tasks the ordering is up to the caller. Both are properties of the code around yours. A recipe for creating an async context is advice you can follow; a recipe for what happens when your third-party dependency is not sendable is a negotiation with reality, and the value of the document is in having the vocabulary to describe the problem to whoever maintains that dependency. ## The Swift 6.0 warning, and what it costs the reader The README carries a warning that any reader of the code has to take seriously, and it is placed where it cannot be missed. The code is not yet updated for Swift 6.0. On top of changes to the language, which the warning describes as substantial, the original author's general understandings and opinions have changed as well. Both halves of that matter, and the second is the more interesting. It is not just that the code needs updating for a new compiler. The judgement behind the code was formed under the older model, and a reader who copies a solution from before Swift 6.0 may be copying a solution to a problem that the 6.0 model reframes. The warning is therefore addressed to the reader's understanding and not only to the code's syntax. The maintainer handles it by asking for help. Feedback and issue reports are explicitly invited, with the note that the reader should keep the Swift 6.0 caveat in mind while reading. That is a reasonable position for a community document: rather than pretending the material is current, it asks the people who are using the current toolchain to say what changed. What it means for you is specific. Treat the recipes as a map of the problem space and a set of solutions from an earlier version of the language, then check each one against the current SDK. The hazard definitions have aged better than the code, because they describe the model rather than the API, and they are the part of the repository that is most likely to remain useful. ## A Swift package with a documentation-first layout The repository is packaged as a Swift project. Package.swift sits at the root alongside Sources/ and Tests/, with Recipes/ as a directory of markdown documents, and the LICENSE file holds the BSD-3-Clause text. The original .gitignore and CODE_OF_CONDUCT.md round out the root. The package structure tells you how the project is meant to be used. A Swift package can be cloned and read like a document, opened in an editor with the recipes as reference, or consumed as a dependency. The Recipes/ directory is named the way a package names a target, and the presence of Tests/ says that some of the examples are code that compiles rather than prose. The contribution guidance is unusually relaxed in one respect and formal in another. The maintainer says issues or pull requests work great, says they would love to find ways to work together if you have a similar project, and then addresses a specific detail: tabs are preferred for improved accessibility, but you should use whatever system you want and make a pull request rather than hesitate because of whitespace. The formal part is the Contributor Code of Conduct, which participants agree to abide by. On maintenance, the repository has no GitHub releases, so there is no version to pin, and the last push was on 2026-08-22. The document is a moving target in the way that all community-maintained prose is, which is another reason to read the hazard definitions and reason from them rather than from any single recipe. ## Where a recipe collection is the wrong tool The first and largest limit is the one the repository states itself. This is not comprehensive, the author says so in the first screen of the README, and a document that admits it is partial is a document you will eventually fall out of. Swift concurrency moves quickly, and a recipe set that is complete in one release cycle is incomplete in the next. The second is the Swift 6.0 gap, which is more than a version number. A team that has migrated its codebase to strict concurrency has a different set of questions from the ones these recipes were written to answer, and the maintainer's warning about the original author's changed understanding is a signal that the answers, not just the syntax, have moved. The third is that hazards are context dependent. The definitions in the README are a vocabulary, and a vocabulary is not advice. Whether timing matters depends on your UI, whether ordering matters depends on your task graph, and whether blocking matters depends on how many threads you are willing to give up in a fixed-size pool. A recipe that solves reentrancy by restructuring an actor may be right for one app and wrong for another, and the repository does not claim otherwise. The fourth is the shape of the artefact. There is no library to depend on, no compiler check, no API you can call, so the verification burden sits with the reader. The best use of this repository is as a second opinion during a design conversation, where naming the hazard precisely is the hard part and the code is the easy part. ## Conclusion ConcurrencyRecipes fits a Swift developer who has hit a specific concurrency problem, such as an actor that reenters across an await or a library type that is not sendable, and who wants a worked solution in prose rather than a framework to adopt. It does not fit a team standardising on Swift 6, because the repository states plainly that the code is not yet updated for Swift 6.0 and that the original author's own understanding changed with the language, and it does not fit anyone looking for a comprehensive reference, since the author says the opposite. Before following a recipe, check the recipe's Swift version against your toolchain and read the hazard definitions first, because the whole document is built on them. The licence is BSD-3-Clause, the last push was on 2026-08-22, and there are no tagged releases. ## FAQ ### What is ConcurrencyRecipes? A collection of documented solutions and hazards for Swift Concurrency, originally created by @mattmassicotte and now maintained by @dimasusername. The recipes are markdown documents under Recipes/ inside a Swift package, and the README states plainly that the collection is not comprehensive and that the author was learning while writing it. ### Is the ConcurrencyRecipes code updated for Swift 6.0? No. The README carries a warning that the code is not yet updated for Swift 6.0, that the language changes were substantial, and that the original author's own understandings and opinions changed as well. The maintainer invites feedback and issue reports while asking readers to keep that caveat in mind. ### Which concurrency hazards does the repository list? Eight: timing, ordering, lack of caller control, sendability, blocking, availability, async virality and actor reentrancy. The README defines them in short paragraphs after the table of contents, so the recipes share one vocabulary. ### What topics do the recipes cover? Seven documents: Creating an Async Context, Using Protocols, Isolation, Structured Concurrency, SwiftUI, Using Libraries not Designed for Concurrency, and Interoperability. ### How can I contribute to ConcurrencyRecipes? Issues and pull requests are both welcome, and the maintainer says they would like to find ways to work together with people running similar projects. The preferred style is tabs for accessibility, but you are asked to use whatever you prefer and open a pull request rather than hesitate over whitespace, and participation means agreeing to the Contributor Code of Conduct. ## Sources - [dimasusername/ConcurrencyRecipes on GitHub](https://github.com/dimasusername/ConcurrencyRecipes) - [Issues](https://github.com/dimasusername/ConcurrencyRecipes/issues) - [License: BSD-3-Clause](https://github.com/dimasusername/ConcurrencyRecipes/blob/main/LICENSE) - [README](https://github.com/dimasusername/ConcurrencyRecipes/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dimasusername-concurrencyrecipes