For an experienced UIKit engineer who last wrote Swift around 2016. 49 days of work: seven weeks at one a day, or at your own pace. The goal: pass a senior iOS interview.
| Pace | 54 lessons in 49 days of work. Most days have one lesson and seven have two; the last two days are practice interviews. A lesson takes about an hour to ninety minutes. |
| Tools | Xcode 27, iOS 27, Swift 6.4 |
| Starting point | Eighteen years of iOS with UIKit. Swift last used around 2016. |
| Projects | Days 1–3: three small projects you set up from scratch in Xcode. Together they make TinyUI, a miniature SwiftUI you write yourself. After that: Trips, one app that grows with each part. |
Swift changed a great deal after Swift 3. Every piece of SwiftUI syntax that looks unusual is really a language feature added since then. This part covers those features on their own, before any SwiftUI.
Lesson 1: Property wrappers. How @Something var works, and what the $ prefix really is.
Lesson 2: Opaque types and existentials: some vs any. Why every SwiftUI view returns some View, and what that promises the compiler.
Lesson 3: Result builders. How a block of views with no commas and no return becomes a single value.
What @Observable and #Preview actually do, and how to read the code they generate.
The rest of modern Swift you will be expected to use without thinking.
Then the interview problem for this part: A helper that will not compile
How a SwiftUI app starts, how a view works, and the preview workflow that replaces build-and-run.
Seeing a view update live as you type, without launching the app.
@main, App, Scene, WindowGroupWhat replaces AppDelegate and SceneDelegate, and what a scene is.
body and some ViewA view is a description, not an object on screen — and what follows from that.
Then the interview problem for this part: The analytics event that fired forty times
Showing content and arranging it. Stacks and modifiers replace most of what you used Auto Layout for.
Showing text, pictures, and icons, and making images fit their frames.
Arranging views in rows, columns, and layers — the replacement for most Auto Layout.
The three-step negotiation between a parent and its child that decides every size.
Each modifier wraps the view before it, so order changes the result.
Tables, scrolling grids, and writing your own container when neither fits.
Then the interview problem for this part: An infinite photo carousel
Where data lives, who is allowed to change it, and how SwiftUI knows which views to update. This is the part interviews probe hardest.
@State and @BindingWho owns a piece of data, and how another view gets to change it.
@Observable modelsData shared across screens, and how SwiftUI knows which views to update.
Passing values down the view tree without threading them through every initializer.
How SwiftUI decides whether a view is "the same view" — the idea behind most surprises.
Then the interview problem for this part: The counter that resets
Scrolling lists, moving between screens, and presenting sheets — all of it driven by state.
List and ForEachScrolling rows of data, and why every row needs a stable identity.
NavigationStack and programmatic navigationPushing screens, and treating the navigation stack as plain data.
One layout that works on iPhone, iPad, and Mac — and at any window size.
Presenting a screen by changing state, rather than by calling present.
Bar buttons, pull-down menus, and a search field that filters your data.
Then the interview problem for this part: A deep link into a navigation stack
Custom shapes, and animation — which in SwiftUI means changing state and letting the framework animate the difference.
Colour that changes across a view, translucent backgrounds, and depth.
CanvasDrawing thousands of things quickly, when one view per thing would be too slow.
How views appear and disappear, and making one view seem to become another.
Then the interview problem for this part: The card that fades instead of growing
Controls, text entry, gestures, and drag and drop.
Buttons, toggles, pickers, and the standard settings-screen layout.
Text fields, keyboards, and moving the cursor from field to field in code.
Taps, drags, pinches — and state that resets itself when the finger lifts.
Moving data between views and apps, and feedback the user can feel.
Then the interview problem for this part: Testing a debounced search
Decoding JSON, loading from the network, and saving to disk.
Codable and JSONTurning JSON into your own types, and reading the error when it fails.
async/awaitFetching from the network in a view, with honest loading and error states.
AppStorage and SceneStorageRemembering small things: user preferences and where the user left off.
Then the interview problem for this part: The take-home, in miniature
async/await, actors, and Swift 6's data-race checking, which together replace GCD. This is as large a change as SwiftUI itself, and interviews for senior roles lean on it.
Running work in parallel with a clear owner, automatic cancellation, and errors that surface.
@MainActorProtecting shared data without locks, and keeping UI work on the main thread.
Sendable and Swift 6 strict concurrencyHow the compiler rules out data races, and how to migrate an older codebase.
AsyncSequence and AsyncStreamValues that arrive over time, and wrapping old callback APIs so you can loop over them.
Where Combine stands in 2026, and how to migrate away from it.
Starting async work from a view so that it is cancelled when the view goes away.
Writing tests for async functions, and what makes them possible.
Testing a debounce or a timeout without making the test wait.
Then the interview problem for this part: Two downloads for one image
Keeping a growing app readable, testable, and fast.
Why small, named views are easier to read and faster to update.
Giving a view what it needs so that it can be previewed and tested.
What to check with a preview, what to check with a test, and how to "test a view".
Why a view re-renders, and how to find the ones that re-render too often.
Then the interview problem for this part: Testing code that depends on today's date
Dark mode, Liquid Glass, accessibility, localization, widgets, shipping — and using SwiftUI inside a UIKit app.
Colours that adapt to light and dark mode without extra code.
The design language introduced in iOS 26, and how your own controls adopt it.
Translating an app, handling plurals, and layouts that survive longer text.
Your app outside your app: the Home Screen, Siri, and the on-device language model.
Archive, upload, test with TestFlight, and submit for review.
Mixing the two frameworks — the way most real apps adopt SwiftUI.
Then the interview problem for this part: Wrapping a UIKit view for SwiftUI
Three timed practice interviews, and a review of whatever is not yet solid.
Timed practice interviews, then a review of everything not yet solid.
Timed practice interviews, then a review of everything not yet solid.
54 lessons in 11 parts, with 11 interview problems. Current to Xcode 27, iOS 27 and Swift 6.4.
Every piece of code on these pages was compiled before it was published, and every screenshot was taken from a running app.