Unwrap: almost 100 Swift lessons, and a codebase that admits what is unfinished

Almost One Hundred Swift Lessons With A Review Each

Underneath sits almost 100 video lessons covering the fundamentals of the Swift programming language, and each one is backed up by an interactive review rather than left as passive watching. The badges at the top of the README pin the floor at iOS-12.0+ for the device and Swift-5.0 for the language. Learning happens on a phone rather than a Mac, and the download costs nothing:

https://apps.apple.com/app/id1440611372

The source is public as well, and the author gives his reason without hedging: he made the code available so that anyone who wants to can see how he structures his code and perhaps learn from it. That framing also sets expectations for anyone opening the repository. This is a shipped application with a screen for every concept, not a tutorial skeleton with a few sample files, and the build instructions treat it that way.

Three Loops: Lessons, Practice, And A Daily Test

The app runs three separate loops and they stack on one another. Lessons are video chapters with written text beside them, and the short chapters called Sixty Seconds can carry a postscript, an alert message shown between the chapter text and the review. That postscript is where the author parks a point he does not want lost in the video. The review itself is the first check on comprehension.

The second loop is the practice activities, where you write code by tapping, dragging or typing, hunt for errors, and predict program output. All of those activity types keep their data as JSON, and the author notes he made samples of each rather than a complete set. The third loop is the daily challenge, a single test of overall language knowledge per day, which is the part that turns scattered lessons into a routine you either keep or drop. What the README does not give is a count of shipped activities, or any rule about how the challenge resets, so the JSON samples are the only window into that content.

Building The Workspace The README Points You At

Building it needs the toolchain the project was written against: Xcode 10.2 and Swift 5.0. Every CocoaPod is checked in to the repository, so a clone is meant to build as soon as you open the workspace:

Unwrap.xcworkspace

The top-level listing deserves a close look because it does not match a plain Xcode template. `Unwrap.xcodeproj/` is there, but no Podfile and no Package.swift appear at the top level, so nothing in this project resolves through Swift Package Manager. Alongside the app source sit `UnwrapTests/`, `Stickers/` for the iMessage sticker pack, `Working/`, `.swiftlint.yml` and `CODE_OF_CONDUCT.md`. First run is where the author expects trouble. He describes the app as feature complete while warning of errors all over the place at least to begin with, and he asks for a report if building or running fails.

The Contribution List With Two Steps Numbered Five

The contribution guide is ordered by difficulty and is the most specific document the project ships. The Easy tier holds six items but only five numbers, because Write new tests is numbered 5 immediately after the item about Sixty Seconds chapters that lack a postscript. Intermediate then repeats the gag with Did I already mention adding tests, which is the clearest sign that the test suite was thin when the guide was written.

Two of those entries matter for anyone planning a real contribution. Redundant code can be refactored, but unused code should be deleted rather than just commented out, and solutions for Free Coding problems that are not currently accepted count as content rather than as bug fixes. The ordering also carries information: performance hotspots and bug fixes sit in the Intermediate tier below typo fixes, so the author ranks polish above new behaviour. Only the JSON samples and localisation concerns reach the same tier, which is where a newcomer with a few weeks of Swift experience is told there is room.

The Storyboard That Grew Too Big For Its Boots

The architecture section is where the project is most honest, and it sits awkwardly next to the feature-complete claim elsewhere. The author writes that the storyboard started off small and grew far too big for its boots, and he gives a specific reason rather than a vague one: many screens are similar. Some UI has already moved into code, but the fix has not been taken. The proposed path is to build a direct copy of the storyboard in code first, then refactor so that similar view controllers come from shared code.

Theme support sits in the same category. The basics were added, the author notes, but it is not implemented or tested yet, and new themes could follow once the groundwork is done. So a reader should treat both the storyboard complaint and the untested theme layer as open items rather than as history. Nothing has been pushed since 2026-07-14, and the repository has no GitHub releases, so there is no tag history to consult when judging how far that refactor got.

English Only, Tests Present, One Unexplained Directory

Three facts about scope sit next to each other in the repository. The app is available only in English, and the author explains the hesitation about localising it in two parts: Swift continues to change, and the videos will get in the way. A test target does exist at `UnwrapTests/`, and the guide asks for more tests rather than repairing an abandoned one. Then there is `Working/`, a top-level directory that the README never explains.

That gap matters for anyone auditing coverage. `CONTRIBUTING.md` is described as the document that walks through how the code is structured and how it works, so it is where the directory layout, the practice activity JSON and the theme code should be documented in detail. Without it, both `Working/` and the sticker pack under `Stickers/` stay opaque, and the eight third-party frameworks and fonts listed in the credits have to be read out of the README instead of from a manifest.

MIT For The Code, No Rights To The Artwork

The licence field on GitHub reads Other, and the README draws the line itself, with all source code under the MIT licence, the assets marked not redistributable, and each dependency's own terms kept inside its Pods directory and repeated on the app's credits screen.

What that means in practice is narrow, and worth settling before anyone forks. The code is readable and reusable while the artwork is not. Hacking with Swift, Swift in Sixty Seconds, Unwrap and the Unwrap logo are all copyright © Paul Hudson 2019, and the iMessage sticker pack borrows logos from other projects with permission rather than under an open grant. The credits name Kitura as © 2019 IBM Corporation and Ray Wenderlich as © 2019 Razeware LLC, alongside objc.io under Kugler & Eidhof GbR and iOS Dev Weekly under © 2019 Dave Verwer. Eight third-party frameworks and fonts back the app, from DZNEmptyDataSet and SDWebImage through Sourceful, which is the author's own library, Zephyr for syncing and SwiftEntryKit for alerts.

Where The Review Step Differs From Reading Alone

The nearest alternative is the writing the same author publishes on the site the repository lists as its homepage:

https://www.hackingwithswift.com

Reading those articles and running the app are not the same activity. A written article ends when you finish it, while Unwrap places an interactive review after every lesson, stores practice activities as JSON, and adds one daily challenge on top. Sixty Seconds chapters make the difference concrete: each can carry a postscript, an alert message placed between the chapter text and the review, which is how the author delivers a point that would otherwise disappear into a video frame. For someone already following the articles, Unwrap is the same material with an answer check attached.

What the project does not offer sits outside that scope entirely. There is no command line interface, no library to import and no server component in the layout, which is `Unwrap/` plus its tests, its storyboard-era UI and the sticker pack. Judge it as a finished app opened on a phone, or as a Swift codebase to study for how one author arranged a large educational project, and the pinned toolchain tells you which of those two jobs it can still do.

Editorial conclusion

Unwrap is worth taking as a study reference if you are learning Swift on an iPhone, and worth skipping if you need a library, a command line tool or current Apple platform coverage. Before planning anything around it, check three things: that Xcode 10.2 and Swift 5.0 still build on your machine, whether the practice activity JSON can carry your own exercises, and how much of the oversized storyboard a fork inherits. Read CONTRIBUTING.md before touching the architecture, and clear the asset terms before you ship anything that is not code.

Frequently asked questions

Official sources

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