SwiftOnSundays and twenty two episodes of live coded Swift you can read

A repository of finished episodes, numbered in broadcast order

SwiftOnSundays is described as completed projects for the Swift on Sundays livestream series, and the repository layout is the clearest description of what it contains. Every episode has its own numbered directory, starting at `001 Memorize/` and running through `022 Pairs/`, with names like `002 FriendZone/`, `003 Friendface/`, `008 DeclarativeUI/`, `010 BetterRest/`, `013 TextTransformer/`, `014 SpotTheScientist/`, `016 JustType/`, `017 Untangler/`, `018 TerminalWizard/`, `019 DadJokes/`, `020 Switcharoo/` and `021 SpeedMath/`.

Those titles tell you something about the series. BetterRest is a reminder or habit app, JustType is a typing tutor, TextTransformer is a text processing utility, TerminalWizard is a command line tool, DeclarativeUI is about SwiftUI patterns, and WatchReactions points at a watchOS app. The naming is ordinary app naming, which is the point: these are small, complete, runnable things rather than libraries of fragments.

The series itself is described as a regular YouTube livestream series from Paul Hudson, and the format is stated plainly: in each episode the team build a new app from scratch, look into an interesting Swift technique, or tackle other interesting challenges, but always using lots of live coding. The homepage of the repository is his YouTube channel, and the project asks readers to subscribe there or to follow him on Twitter for reminders about the next livestream.

So the repository is the archive of that series, and the value proposition is stated in one line: it stores the completed code we built each week, so you can try it out, or compare your version against the originals.

The directory numbering is a small but useful convention. It lets a viewer who watched episode 12 find episode 12, and it lets a reader browsing the tree see the shape of the series in one screen.

The code is free to use with no credit, and the branding is not

The licensing position is unusual enough to state precisely, because it has two halves that point in different directions.

The first half is the code. Unless otherwise noted, all code in the repository is free to use however you want, commercially or otherwise, with no need to provide any credit to Paul. That is a permissive grant with no attribution requirement, which is broader than most open source licences and simpler than most. A team can lift a project into a commercial product without a notice file, and does not need to open source anything in return.

The second half is the branding. Swift on Sundays is a free YouTube series from Paul Hudson, and Hacking with Swift, Swift on Sundays, and the Swift on Sundays logo are all copyright of Paul Hudson, dated 2019. So the word free applies to the code, not to the name or the logo. A repository that carries the logo in its own banner is not granting you the right to publish a product called Swift on Sundays.

The licence field in the package metadata is left as unknown, which is what the tooling makes of a custom grant expressed in prose rather than in a licence file. For anyone who needs a standard licence identifier, the terms stated in the project documentation are the terms, and the fact that they say no credit is needed is the part that matters most in practice.

The project documentation also points at a wider body of tutorials, describing a whole website full of free Swift tutorials at Hacking with Swift, which is where the series fits in the larger catalogue.

The Vapor episodes ship without their dependencies, on purpose

There is one practical note in the project documentation that determines whether half the repository will build on your machine.

Projects that use Vapor do not ship with their Vapor dependencies or their Xcode project, and you should run `vapor build` and or `vapor xcode` locally to get the latest versions of the Vapor dependencies.

So for the Vapor based episodes, cloning the repository gives you the source and a package manifest, and the Swift toolchain plus the Vapor CLI fetches the rest. `vapor xcode` regenerates the Xcode project, which is why it is missing from the repository in the first place: an Xcode project contains absolute paths and machine specific settings, and a generated one is always more correct than a committed one.

The two commands to run are `vapor build` and `vapor xcode`, in that order if you want both the library and the regenerated project.

For the projects that do not use Vapor, the ordinary expectation applies, and the badges at the top of the documentation give the floor the whole series was written against: iOS 12.0 and later, and Swift 5.0.

Those numbers are worth pausing on. A series targeting Swift 5.0 and iOS 12 predates the current generation of Swift concurrency, the current SwiftUI lifecycle, and current Xcode requirements. That does not make the code wrong, and much of it is still perfectly idiomatic, but it does mean the code is a snapshot of a particular era of the language and of Apple's toolchain, and someone picking it up today should expect to adjust it to their current SDK rather than drop it into a modern project unchanged.

Twenty two projects that span three different styles of Swift

The most useful way to read the repository is as a sampler across approaches rather than as one coherent project.

The obvious grouping is by UI framework. Some episodes are Vapor server applications, which is where the named apps such as TerminalWizard and DadJokes sit. Others are SwiftUI, which is what DeclarativeUI and the cup-shaped app named `009 CupcakeCorner/` and `015 WatchReactions/` are about. And a third group is plain Swift, command line or platform code with no UI at all, which is where the algorithmic names like `005 iMultiply/`, `012 MultiMark/`, `017 Untangler/`, `021 SpeedMath/` and `022 Pairs/` sit.

That third group is the most reusable part for a developer learning the language, because the techniques in it are about Swift as a language rather than about a particular framework, and the code is small enough to read in one sitting. `019 DadJokes/` and `020 Switcharoo/` read as UI experiments, `013 TextTransformer/` and `018 TerminalWizard/` as utilities.

What the series is doing, according to the project documentation, is looking into an interesting Swift technique as often as it is building an app. That is the pedagogical value: a finished project demonstrates one idea well, whereas a tutorial of the same idea teaches it inside whatever the surrounding code happens to be.

The streaming format has an implication for the code too. Code written live, under a deadline, in front of an audience, is not the code a professional would ship, and the project documentation is not claiming it is. What it claims is that you can try it out, or compare your version against the originals. That second use, comparing your own solution against a working one, is where the archive is worth the most.

What you cannot learn from this repository

There are three things a reader should not expect here, and each is a normal property of a teaching archive rather than a defect.

The first is production quality. The projects are demonstrations, so they carry the assumptions of a demo: no error handling policy, no test suite described anywhere in the project documentation, no accessibility review, no localisation beyond what the episode needed, and no persistence layer beyond what the app required. The repository listing shows a `tests/` directory in other projects but nothing here about testing, and the project documentation does not mention it.

The second is current API guidance. The badges pin iOS 12.0 and Swift 5.0, and the episodes were recorded against the toolchain of their day. Anyone using this as a reference for a modern project should read the code as a reference to a technique and then check the current documentation for how that technique is done now, because the idioms that have shifted most are the ones around concurrency and around the SwiftUI app lifecycle, and those are exactly the areas a modern codebase is most likely to be judged on.

The third is that nothing here is maintained as a dependency. There is no package you add, no version you pin and no release notes to read. The repository publishes no GitHub releases, and the last push was on 2026-06-12, so the newest episode in the tree is also the most recent work. The code is a reference and a starting point, and the licence explicitly allows you to make it yours, which is the point of a teaching archive.

The value of the archive is also uneven across episodes, which is the nature of a series rather than a defect in any individual project. Some episodes solve a problem you have; others solve a problem the author wanted to explore. With twenty two of them, there is a good chance at least one lands on the technique you are stuck on.

The series is a funnel, and the repository is the bottom of it

The repository sits inside a larger structure, and reading it that way explains the choices in it.

The project documentation points to a YouTube channel and a Twitter account for reminders about the next livestream, to the Hacking with Swift website for free Swift tutorials, and to the repository for the completed code. The website is described as a whole website full of free Swift tutorials, which is the wider catalogue the series belongs to.

So the flow is deliberate: watch the stream, follow the tutorials, clone the code. Each of the three is a different depth of engagement with the same subject, and the repository is the one that asks for the most effort from the reader, because reading code is slower than watching.

That also explains why the repository is thin. There is no per-project readme in the tree, and the top level documentation points out that the completed code is there so you can try it out or compare your version against the originals, which is the language of a companion to a video rather than of a standalone project with its own documentation.

The community shape follows the same pattern. There is a `.gitignore` and a `README.md` at the top level of the tree, and the visible top level is nothing but the episode directories and that documentation file. There is no issue tracker guidance, no contribution guide and no licence file, which for a repository of this kind is reasonable, since the intended interaction is to clone and run rather than to file a pull request.

For a reader deciding whether to spend an evening in here, the answer is that the archive is genuinely free to use, the code is small and self-contained, and the numbering makes it easy to jump to the episode whose subject matches the problem in front of you.

Editorial conclusion

SwiftOnSundays fits a Swift developer who learns better from finished code they can run and modify than from a tutorial that explains each step, and who wants twenty two working examples across Vapor, SwiftUI and plain Swift to browse. It is the wrong place to look for a maintained library, since nothing here is a dependency you would take, and the wrong place to look for current guidance, because the episodes are dated artefacts of when they were recorded. Before using a project, check two things: what the badge tells you about the platform floor, since the series targets iOS 12.0 and Swift 5.0, and that a Vapor project actually builds, because the Vapor ones deliberately ship without their dependencies and without an Xcode project. The code is free to use commercially or otherwise with no need to credit the author, while the series branding itself is copyrighted by him.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. twostraws/SwiftOnSundays on GitHub