Stanford CS193p： iOS Development with SwiftUI ｜ L10： Building Complex UIs — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course:

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 moves beyond basic layouts to tackle the construction of complex, data-driven user interfaces. It covers SwiftUI's List and Form views for displaying structured data, navigation stacks and navigation links for multi-screen workflows, and sheet presentations for modal content. The lecture also discusses how to efficiently render large datasets using lazy containers, how to customize list row appearances, and how to manage navigation state in a clean, maintainable way.

These notes cover Stanford CS193p Lecture 10, Building Complex UIs. This session was almost entirely live coding, walking through how to build multi‑screen SwiftUI interfaces. A big focus was understanding protocol requirements like Identifiable, Hashable, and Equatable, plus practical UI components including List, NavigationStack, toolbars, and the trade‑offs between struct and class model types. I tried to flag spots that confused me while watching, so you can catch tricky points without sitting through the full recording.
 

Working with For‑Each and Collection Identity Rules

The lecturer kicked off by refactoring existing code that rendered user guess attempts in the Codebreaker game. Originally the loop pulled array indices to render each entry, then reversed output so the newest guess appeared at screen top (0:35). They wanted to iterate directly over attempt objects instead of indices, which would make the view code cleaner.

Switching to looping over the items themselves created compiler errors. SwiftUI’s For‑Each needs three properties for the identifier it uses to track views: uniqueness, stability, and conformance to Hashable. The original code did not guarantee unique guess entries. In one of the course’s prior assignments, students were forced to block duplicate guess submissions, but this demo code allowed sending in identical guesses multiple times. Duplicate values break For‑Each, because SwiftUI cannot reliably map which data item connects to which on‑screen view when items shift around (2:10).

The instructor first tried making the custom Code struct conform to Hashable. Swift can auto‑synthesize protocol conformance for structs, but only if every stored property inside also meets the protocol requirements. The compile error pointed to an inner enum Kind, which supported Equatable but not Hashable. Updating Kind to Hashable fixed that dependency chain (4:20). Even after compiling, there was still a functional flaw: duplicate guess values could still get created. So they added a check before accepting new guesses, rejecting any guess whose peg sequence already existed in the attempts array.

Even with this working, the lecturer pointed out they had done unnecessary work. They did not actually need the whole Code type to be Hashable. The pegs array inside each attempt already satisfied uniqueness, stability and Hashable. They could just explicitly point For‑Each to use pegs as the identifier, instead of making the whole struct conform.

Next they walked through making Code conform to Identifiable. Swift cannot auto‑synthesize Identifiable for structs. Unlike classes, structs have no built‑in sense of inherent identity. You have to manually define the id computed property. The Xcode fix‑it tool auto‑generates a placeholder id variable, and the demo set id to return the pegs array. Even though the syntax looked nice, the lecturer said they would not actually write this for real‑world code.

One point that was hard to follow here is the semantic argument against conforming Code to Identifiable. While pegs uniquely identify a guess attempt within this specific game screen, pegs are not the true inherent identity of a Code value in every context. Imagine an array mixing master secret codes and user guess codes. Two different logical entries could share identical peg values, so pegs would no longer work as an identifier (11:50). Writing .id(\.pegs) on the For‑Each makes your intent explicit: you are choosing pegs as the identifier for this particular view loop, rather than claiming pegs represent the universal identity of the struct everywhere in your app.

This whole segment drove home a core lesson: protocols like Identifiable describe requirements for a specific usage context, not just something you add to a type just to make compiler errors disappear.
 

Building multi‑screen interfaces with List and NavigationStack

After finishing the For‑Each refactor, the lecture moved to building a game‑choosing screen. The goal was to change the app’s root interface. Instead of opening straight into one Codebreaker game, launch into a list showing multiple game variants. Users tap a list entry to jump into playing that particular game (13:08).

They created a brand‑new SwiftUI view called GameChooser. This view holds an array of Codebreaker game instances as local state. A List view displays the collection. The lecturer described List as a pre‑built combination of VStack, ScrollView, dividers, and For‑Each. It appears everywhere across iOS system apps like Settings, and you will reach for it most times you need to show users a selectable list of items (14:50).

They added sample game themes inside an .onAppear modifier, populating the list with mastermind‑style colours, earth‑tone colours, and underwater blue‑toned colour sets. Next they pulled the row content into its own standalone subview named GameSummary. Breaking row content out to a separate view keeps the List body clean and also makes writing previews simpler. The preview can wrap GameSummary inside a List to replicate real runtime layout, instead of previewing it in isolation (28:00).

While building GameSummary, they demonstrated Swift’s built‑in pluralization text inflection. Instead of writing ternary logic to manually add an “s” for plural nouns, Swift has locale‑aware inflection. This matters because not every human language forms plurals by simply adding an s character (23:30).

They also touched on List styling options. Two major styles are plain and grouped. Grouped is what you see in iOS Settings, with visual group boundaries. Plain style works better for simple selection lists like this game chooser. You can also apply modifiers to individual list rows: hiding separators, custom row backgrounds and corners. They briefly demonstrated Section, which divides a list into labelled groups, like how Settings separates categories. They noted they would not use sections for this app, but showed the syntax so the class knew how it works (30:04).
To enable tapping list rows and moving to the game‑playing screen, they added NavigationLink. A common gotcha they demonstrated: NavigationLink does nothing if it is not nested inside a NavigationStack. Without that container, all links are inert and taps do not register (33:55).

Now there was a new data‑sharing problem. The original CodebreakerView owned its own game model with @State. The game chooser needs to hand over one of its existing game objects to that view, and any edits made while playing need to flow back to the chooser screen so the summary view updates attempt counts. They converted the view’s stored property to @Binding. This required adjusting previews, since previews have special rules when working with @State and @Binding (35:30).

When you use List with a binding‑based collection, you can use the dollar‑sign syntax directly in List’s initializer. This lets you get bindings to each individual element inside your array state. This special syntax enables built‑in edit actions: swipe‑to‑delete rows, plus edit‑mode reordering controls (37:15).

Toolbars live inside the NavigationStack context. The .toolbar() modifier attaches toolbar content to the currently‑active view inside the navigation stack. That means different screens can show different toolbar buttons. When you navigate away from a view, its toolbar items disappear automatically. They moved the game’s restart button and elapsed‑time timer into the toolbar. ToolbarItem lets you control placement, using semantic placement values instead of hard‑coding left or right positions. Semantic placement lets SwiftUI adapt automatically for different device sizes like iPhone versus iPad (46:50).
 

Switching model from struct to class with ObservableObject

Up until this point, Codebreaker was a value‑type struct. The lecturer walked through converting it to a reference‑type class, explaining the practical consequences for SwiftUI (51:35).

Struct methods can have the mutating keyword. Classes do not need mutating markers. Every method on a class can modify its stored properties, because you work with a reference pointing to heap memory. Changing to a class broke how SwiftUI observed changes. Simply passing the class instance around is not enough. SwiftUI has no way to detect mutations happening inside heap‑allocated objects unless you mark the class with @Observable. Without @Observable, UI would not refresh even when model data changed. The selection state held inside the view’s @State variables would still update, because that state belongs to the view layer, not the model (55:10).

Once your model becomes a class, you can no longer use that special dollar‑sign List initializer for automatic swipe delete and reorder. You have to use a manual ForEach with .onDelete and .onMove modifiers. Those handlers receive index sets, and you call array mutation functions to delete or reorder items in your source array (56:40).

Classes get automatic Identifiable synthesis. The built‑in identity comes from the reference address in memory. But to use value‑based NavigationLink (the variant that takes a value parameter and uses a separate .navigationDestination(for:) modifier), your class also needs Hashable conformance.

I found this section confusing. Even though the class automatically gets Identifiable, Hashable is not synthesized. You have to manually implement == and hash(into:). The implementation shown relies entirely on the built‑in id property that Identifiable synthesizes. Two instances are equal only if they are exactly the same object living at the same memory location. This is strict reference equality, not value equality. Two separate class objects holding identical game data would count as not‑equal, even if every property matches (1:03:20). The lecturer recommended putting these protocol conformances inside an extension on the class, to keep the main class definition cleaner.

Using the value‑based NavigationLink pattern has one big performance upside. All destination views do not get instantiated when the list draws. The destination view only gets created when the user actually taps the link. If you have a long list, you avoid creating dozens or hundreds of unused destination views sitting in memory (1:00:18).

They also showed you can have multiple different .navigationDestination(for:) modifiers on the same NavigationStack. In the demo they added a cheat button link. One link navigates to a Codebreaker view given a Codebreaker instance. A second separate link navigates to a simple peg‑display view given just an array of pegs. SwiftUI matches the type of value passed in NavigationLink against each navigation destination, and renders the matching view (1:07:30).
 

Unanswered points and looking ahead

The lecturer pointed out multiple unresolved items for future lectures and assignments. Right now all game data lives only in app memory. If you close and restart the app, every game resets. Persistence will come in a later assignment, so students would temporarily live with losing game state on app restart (1:10:00).

This lecture also skipped supporting iPad and MacOS platforms. The next session would cover adapting this multi‑screen UI for those larger form‑factors. Future work would also add UI for creating entirely new games from scratch and editing existing game themes to add new peg colour choices.

One limitation that stood out to me: the strict reference equality for the Codebreaker class. If you wanted to compare two different game instances for logical value equality (all pegs, attempt lists, name matching), the Equatable implementation shown would not work. The lecturer only implemented reference‑identity equality for the purpose of satisfying Hashable for NavigationLink. They did not show how you would write value‑based equality checks for this class. That feels like an open question from this lecture.

Also, when using Observable classes, you have to be mindful of shared references. Multiple views hold references to the exact same object. Accidental side‑effect mutations can pop up in places you might not expect, which is a trade‑off compared to struct value semantics. The lecturer touched on this risk briefly but did not go deep on debugging reference‑type side‑effects.