Stanford CS193p： iOS Development with SwiftUI ｜ L4： CodeBreaker's Model — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CS193p: iOS Development with SwiftUI | 2025 | L4: CodeBreaker's Model

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 applies the model-view separation principles from the previous session by building out the complete data model for the CodeBreaker application. It walks through the design of model structures to represent game state, guesses, and match results, and demonstrates how to encapsulate game logic within the model layer independent of any UI code. The session emphasizes good modeling practices including immutability where appropriate, computed properties, and methods that mutate state in controlled, predictable ways.

These notes cover lecture four of Stanford’s CS193p iOS course from spring 2025. The whole session builds out the CodeBreaker game, focusing on separating the model layer from the user interface. I will walk through the practical Xcode workflows, Swift language concepts, and design decisions the instructor demonstrated, while flagging spots that felt confusing or had trade‑offs worth thinking about. The core keyword here is CodeBreaker, which we will come back to repeatedly as we unpack the model‑UI separation pattern.
 

Building the CodeBreaker Model from Scratch

The lecture opens with the instructor pointing out their existing CodeBreaker project was little more than a prototype. Hard‑coded test values filled the UI, with no real game logic living separately from the view code (00:38). The primary goal for this lesson was to create a fully functional game model, then rewrite the UI so it simply reflects whatever state lives inside that model.

In Xcode, to create model‑only code you make a plain Swift File template, not a SwiftUI View template. Model files should import Foundation, not SwiftUI. The instructor deliberately broke this rule during the demo for expediency, importing SwiftUI‑Core instead. They explicitly told students to revert this for assignment two, because a clean model should have zero dependencies on UI‑related frameworks (02:07).

The root of the model is a struct named CodeBreaker. Structs are value‑types, and most of your model objects in SwiftUI apps start as structs. The instructor noted that later in the quarter the CodeBreaker model would even shift to using a SQL database, showing structs are just a starting point, not the only possible model storage (01:03).

When brainstorming what data CodeBreaker needed to store, they broke down the game state. There is a hidden master code the player is trying to guess, an in‑progress guess the user is editing, a history of past guess attempts, and a list of available peg color options (04:25). None of the actual drawing code lives here. The model holds data and game rules only.

Two nested types quickly became necessary: a Code struct to represent sequences of pegs, and a way to represent individual pegs. Rather than writing a full struct for pegs, the instructor used a typealias that mapped Peg directly to Color. This is mostly for readability. You are still just using Color underneath, but the alias makes your variable names communicate domain logic. They flagged this as a temporary hack, though. Color is a UI‑layer type, sensitive to light and dark mode rendering, so keeping it in the model violates clean separation (10:55). Assignment two tasks learners to replace this alias with String, storing color or emoji names as plain text data. The UI will then convert those strings into visual representations.

Inside the Code struct, the instructor created an inner enum called Kind. This enum has three cases: masterCode, guess, and attempt. This is namespacing. Writing the enum inside the struct means its full name is Code.Kind. You do not pollute the global namespace with a bare‑named enum. Inside Code.Kind, later in the lecture they added associated values only for the attempt case. Attempt codes needed to store match result data (black‑and‑white hint pegs), but master and guess codes had no need for that extra data. Associated enums let you attach data only to specific cases, instead of forcing every instance to carry unused properties (53:37).

I found this section on nested enums and associated values really useful, though it moved fast. One thing the instructor glossed over was when you should nest a type versus declare it at file scope. Their loose guideline was: if a type is tightly coupled and only makes sense inside its parent type, nest it. If it has independent meaning, keep it top‑level (09:17).
 

Wiring Model and UI, Managing Mutable State

Once the basic model structs and enums existed, the next big hurdle was connecting the CodeBreaker model to the SwiftUI view. The view should act purely as a visual manifestation of the model data (00:50). The instructor renamed the default ContentView to CodeBreakerView using Xcode’s refactor‑rename tool. This updates the struct name, filename, preview, and app entry point all at once, without manual search‑and‑replace. This is a key workflow tip for SwiftUI projects (18:33).

When they first tried to instantiate CodeBreaker inside the view, Swift complained about missing arguments for all stored properties. Every stored property in a struct must have a value. The UI should not be responsible for manually filling in master codes or guess data. So they added default values directly inside the model definition (14:17).

A major pain point showed up when adding model methods that modify struct state. They wrote a mutating function changeGuessPeg(at:) to cycle peg colors when the user taps a peg in‑progress guess. Because structs are value‑types, any function that changes the struct’s stored data must be marked mutating (34:32).

This created a conflict inside the SwiftUI view. Views themselves are structs, and their body property is computed read‑only. You cannot call mutating functions on a plain let or even plain var stored property inside a view struct. The fix they demonstrated is the @State property wrapper.

@State moves your model value out of the view struct’s own memory and stores it on the heap inside a reference‑type box. Even though the view struct itself stays immutable, you can call mutating methods on the wrapped value. A huge benefit the instructor highlighted is traceability: you can search your view for @State and immediately locate every source of mutable truth in your UI (37:41).

Once the model variable was wrapped in @State, tap gestures on pegs worked. The view passes user interaction events to model methods. The model updates its own state, and SwiftUI’s reactive system automatically recomputes the relevant parts of the view body. You never manually call “update UI” functions.

Next they built a Guess button, which called another mutating model method attemptGuess(). This function copies the current guess value, changes its kind property to attempt, then appends that copy to the attempts array. This shows off value‑type copy‑on‑write behaviour. Modifying the copied attempt does not alter the original guess variable at all (43:17). If this had been a reference‑type class, changing the copy would have mutated the original guess too, which would break game logic.

The UI had several usability problems they fixed with simple SwiftUI containers. The list of past attempts could push content off‑screen, and tapping guess shifted the button position. Wrapping content in a ScrollView fixed both. They also reversed the indices when iterating over attempts, so the most recent guess appeared closest to the editing area (46:59). Adding withAnimation {} around state changes created smooth transitions, though they noted the default animation behaviour was imperfect and would get deeper coverage in a later lecture.
A tricky UI bug popped up when they set blank pegs to a clear color. A fully transparent view ignores tap gestures. The solution they used was the contentShape() view modifier. It tells SwiftUI to treat a view as having a given shape for hit‑testing purposes, independent of its visible opacity (1:04:37). This lets invisible placeholder shapes still receive user taps.
 

Unanswered points & limitations demonstrated in‑lecture

This section covers some of the compromises and open homework problems shown in the lecture. These are points the instructor flagged, rather than things I figured out on my own.
First, the temporary typealias Peg = Color shortcut. The instructor repeatedly stressed this is bad model‑UI separation. Color is a UI‑framework type, aware of dark‑mode adjustments. The proper fix for assignment two is changing Peg to alias String. The model stores only text identifiers like emoji characters or color names, and all actual color rendering work shifts entirely into view‑layer code (11:44). The instructor tossed out a fun optional challenge: write helper code to convert string names to SwiftUI Color values, and even joked about using AI tools to help write that conversion logic.

Second, the enum Code.Kind gaining associated values broke automatic Equatable synthesis. Enums without associated data automatically get Equatable conformance from the Swift compiler. Once you add associated payloads, the compiler stops generating equality logic. If every piece of associated data itself conforms to Equatable, you can still get synthesized Equatable by explicitly declaring conformance. Otherwise you have to implement == manually (56:32). The compiler error that arises can cause very long build times in SwiftUI because ViewBuilder struggles to validate your view body when types lack expected conformances.

Third, the tap‑to‑cycle‑peg‑colors interaction. The instructor admitted this is not great user experience. Tapping repeatedly to cycle through options is clunky on mobile. They said in the next lecture they would implement a dedicated peg‑selection keyboard UI, which would be far more natural for players (24:59). So what we built here was more a teaching vehicle for tap gestures and model mutation, not production‑grade UX.

Fourth, when initializing the CodeBreaker struct, they wrote a custom init() that randomizes the master secret code. They also added an init parameter for pegChoices with a default argument. One subtle gotcha they walked through is naming init parameters identically to stored properties. You need the self. prefix inside the initializer to disambiguate between the incoming function argument and the instance’s own stored property (1:08:48). Even let properties can receive their value inside an initializer.

The lecture wraps by previewing assignment two requirements for CodeBreaker. Students must adapt the model so pegs can represent emoji faces alongside colors. Since pegs become strings, the view must map those string identifiers to visual content. They also showed how to add a stroke border overlay for blank pegs so users can visually see where to tap even when no peg is drawn.

Throughout the lecture, every new visual element is built on top of model state. The view never holds game data of its own. All business logic, randomization, guess evaluation, and state changes belong in the model structs. That separation is the big takeaway for working with SwiftUI, and the CodeBreaker example makes it concrete.