Stanford CS193p： iOS Development with SwiftUI ｜L2： Code Breaker App — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CS193p: iOS Development with SwiftUI | 2025 | L2: Code Breaker App

Instructor Bio: This lecture is delivered by Paul Hegarty, Lecturer in Computer Science at Stanford University and the principal instructor of CS 193P since 2010. Paul Hegarty is a veteran software engineer and educator with deep roots in the Apple developer ecosystem. Earlier in his career he worked at NeXT Computer, where he contributed to the Objective-C language and the foundational tools that would eventually become Apple's modern development platform. He has taught iOS application development at Stanford for over fifteen years, guiding thousands of students through the transition from earlier UIKit frameworks to the modern SwiftUI declarative paradigm. He is widely recognized for his methodical teaching style, his emphasis on clean architectural patterns such as MVVM, and his ability to explain complex systems concepts through hands-on, live-coding demonstrations.

Course Description: This lecture continues building foundational SwiftUI skills, covering a broader set of view modifiers including .fill(), .stroke(), and .opacity(). It introduces custom structs that conform to the View protocol, demonstrates how to organize views across separate files for maintainability, and uses enumerations to represent discrete states such as match results (exact, inexact, no match). The session also introduces functional programming concepts like count(where:) for array processing, and begins construction of the quarter's flagship project — the CodeBreaker game application.

This is the second lecture of Stanford’s CS193P Spring 2025 course on iOS development with SwiftUI, and it stays almost entirely in live demo mode rather than slide-based lecture. After a quick recap of the view basics covered last class, the instructor walks through view modifiers—one of the two core pillars of building SwiftUI interfaces—then starts building the full UI for a Code Breaker game, the class’s ongoing project. Along the way, they drop practical tips for structuring SwiftUI code, avoiding common compiler slowdowns, and working with built-in shapes and controls.
 

Recap: The Basics of SwiftUI View Composition

The lecture opens with a roughly three-minute recap of the first class’s core ideas, to make sure everyone is on the same page before moving forward.

All user interfaces in SwiftUI are built out of views—small, reusable pieces that you combine like Lego bricks. To make your own view, you create a struct that behaves like a view, which means it has a computed property called body that returns some other view. You build larger views by nesting smaller ones inside container views like VStack (vertical arrangement), HStack (horizontal), and ZStack (layered on top of each other).

The instructor emphasizes that you almost never need to think about the underlying @ViewBuilder system that powers these containers. It works behind the scenes to turn the list of views you write inside a stack into a single combined view, and its exact internal behavior doesn’t matter for most day-to-day work.

They also quickly touch on the app entry point: the @main struct that conforms to the App protocol, with a WindowGroup containing your root view. Most of this is boilerplate on iOS, since iOS apps typically only have one window, but the structure exists to support multi-window apps on macOS.

I found this recap well-paced and helpful, especially since the first lecture threw a lot of new syntax at you very quickly.

View Modifiers: The Other Pillar of SwiftUI

After the recap, the instructor introduces view modifiers as the second major foundation of building interfaces with SwiftUI, alongside views themselves.

View modifiers are simply functions added to the View protocol—so every view gets access to hundreds of them. You call them with dot syntax, right after the view you want to modify. Each modifier returns a brand new view with the change applied, rather than changing the original view. This is what lets you chain multiple modifiers one after another.

Order matters a lot, and this is one of the most common early mistakes. The instructor demonstrates this with padding and background color: if you add padding first, then a background color, the color fills the whole padded area. If you reverse the order, the color only fills the original text, with blank padding around it. You can use this order dependency to your advantage to get exactly the look you want.

One of the more subtle but powerful behaviors is how modifiers interact with container views. If you apply a modifier like .font(.largeTitle) to a VStack, the stack itself doesn’t use the font—it passes it down to every child view inside it. Any child that sets its own font will override the inherited one, with the closest modifier always winning. The instructor frames this as a default system: containers set defaults, and individual views can override them.

Not all modifiers do something on every view. For example, adding a font modifier to a Circle shape does nothing visible. But system images (like the built-in globe icon) do respond to font modifiers, because they’re designed to scale alongside nearby text.

I found the chaining and order logic really intuitive once you see it demoed live, but the inheritance rule took a minute to sink in. It’s easy to assume modifiers only affect the thing you directly attach them to, until you see a whole stack of text resize from one line of code.

The instructor also teases that even animation, covered later in the course, boils down to animating changes to view modifier values. That makes the whole system feel much more cohesive—there’s no separate animation magic, just changes to the same modifiers you already use.
 

Building the Code Breaker Game UI

The majority of the lecture is a live demo building the interface for Code Breaker, the class’s version of the classic Mastermind board game. For anyone unfamiliar, it’s a logic game where one player sets a secret four-color code, and the other guesses repeatedly. After each guess, you get feedback: a black peg for each correct color in the correct position, and a white peg for each correct color in the wrong position.
 

From copied code to reusable functions

The instructor starts simple: four Circle shapes in an HStack, each with a different foreground color, to represent one row of guess pegs. To make multiple rows, they nest several of these HStacks inside a VStack.

Almost immediately, they call out the problem with this approach: copying and pasting nearly identical code is almost never the right move in programming. First they extract the peg row into a computed variable, so you can reuse it multiple times. But a variable always renders the same colors, so they upgrade it to a function that takes an array of colors as a parameter.

This leads into a big emphasis on decomposition—breaking large views into smaller, self-contained pieces. The instructor gives two concrete reasons this matters. First, it makes your code readable; deeply nested stacks inside stacks are hard to follow. Second, it drastically helps compiler performance. Very large view bodies can force the Swift compiler to spend minutes trying to infer types, and sometimes it simply fails with a generic error. Decomposing into smaller views gives the compiler fewer possible type paths to check, so errors show up faster and builds run quicker. This is one of those practical tips you don’t usually get in introductory courses, and it feels extremely valuable.
 

Using ForEach to build dynamic views

You can’t use regular for loops inside a SwiftUI view builder—only if statements and let constants. To render a view for every item in a collection, you use ForEach, which is itself a view that generates content from your data.

The instructor walks through a very common gotcha here. ForEach needs a unique identifier for every element in your collection, so it can track which view is which (critical for animations later). At first it seems like you can use the color itself as the identifier, but that breaks when you have duplicate colors in the same row—like two green pegs. With no way to tell the two greens apart, ForEach can’t work correctly.

The fix they demonstrate is to iterate over the indices of the color array instead of the colors themselves. Array indices are always unique, so the problem goes away. You then just use the index to look up the corresponding color inside the ForEach content.

I found this part really well taught. Instead of just stating the rule, they show the problem first, let the error happen, then walk through the fix. It makes the reason for the ID requirement stick much better.
 

Feedback pegs and shape modifiers

Next they build the small 2×2 grid of feedback pegs that sit next to each guess row. These are smaller circles that show black (exact match) or white (color match, wrong position) markers.
They use this as a chance to demonstrate shape-specific modifiers. Unlike regular view modifiers, shape modifiers only apply to shapes. The two main ones are fill (sets the inside color) and stroke (draws an outline). They also show strokeBorder, which draws the outline inside the shape’s bounds instead of half-in half-out, so it doesn’t spill past the view’s frame.

Other modifiers come up here too. The aspectRatio modifier forces a view to a given width-to-height ratio—1:1 for a perfect square. The opacity modifier hides a peg entirely when set to 0, which is useful for empty feedback slots without breaking the 2×2 grid layout.
 

Extracting views to their own files

Toward the end of the demo, the instructor extracts the feedback peg grid into its own view struct called MatchMarkers, then moves it entirely into a separate file. They show a handy Xcode shortcut: you can cut a view struct, then use “New File from Clipboard” to automatically create a new file with that code in it.

They note two quick requirements for standalone views: you need import SwiftUI at the top of the file, and you can add a #Preview block at the bottom to see the view in the canvas without running the whole app.

Enums, Match Logic, and Preview of Next Lecture

In the final ten minutes, the instructor starts adding data structure support for the game’s feedback logic, and teases topics for the next class.

First they introduce enums (enumerations) as a data type that can only be one of a fixed set of cases. They create a Match enum with three cases: noMatch, exact, and inexact. This is much cleaner than using numbers or strings to represent match states, because the compiler will catch typos and invalid values for you.

They update the MatchMarkers view to accept an array of Match values as a parameter, instead of hardcoding the peg appearance. Then they build a helper function inside the view that returns the correct circle style for each peg position:
 

• If the peg number is less than the count of exact matches, draw a filled primary color peg.

 

• If it’s less than the total number of matches (exact plus inexact), draw a stroked outline peg.

 

• Otherwise, draw a fully transparent peg.

To count the exact and total matches, they use a single line of code with matches.count(where:). This is functional programming syntax, where you pass a condition to the count function. The instructor explicitly says they won’t explain this fully today, and will break down how it works at the start of the next lecture.

I found the ending a bit abrupt. The count(where:) line is powerful, but if you’ve never seen closure syntax before, it looks like total gibberish. It’s smart of them to pause and come back to it, but it does mean this lecture ends on a confusing note rather than a clean wrap-up.

They also preview what’s coming next class: separating the game logic (the model) from the UI, plus a deeper dive into basic Swift language features like structs, generics, optionals, and extensions that are covered in the first reading assignment.

All in all, this lecture does a great job of moving past basic syntax and into the real workflow of building apps with SwiftUI. The live demo format means you see both the right way to do things and the common mistakes along the way, which feels much closer to actual development than a slide-only lecture. The biggest takeaways are the power of view modifiers, the importance of decomposing views early, and the way ForEach connects data to UI.