Stanford CS193p： iOS Development with SwiftUI ｜ L6： Demonstrating Data Flow — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CS193p: iOS Development with SwiftUI | 2025 | L6: Demonstrating Data Flow

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 is a hands-on demonstration that puts the data flow concepts from Lecture 5 into practice within the CodeBreaker application. It shows how to wire up observable view models, pass bindings between parent and child views, and manage shared state across multiple screens. The session also covers how to handle user input events, validate state transitions, and ensure that the UI remains consistent with the underlying model at all times, reinforcing the reactive programming model at the heart of SwiftUI.

These notes cover Stanford CS193p Lecture 6, focused on SwiftUI data flow. Almost the whole session is live coding on the Code‑Breaker game project. The instructor walks through refactoring views, learning @State, @Binding, good code organisation patterns, and debugging common pitfalls. Much of what is shown directly applies to Assignment 3, which builds a word‑guessing app similar to Wordle.
 

Xcode refactoring tricks and view decomposition

The lecture opens with the instructor demonstrating Xcode refactoring tools (00:08). He recreates a mistake from the prior class: accidentally triggering “Extract to File” instead of renaming a struct. This leads into a demonstration of that feature. When you select a struct and run extract‑to‑file, Xcode creates a new Swift file, moves the type there, and keeps all references working. This is handy when you start with multiple structs in one file and want to split them apart as code grows.

He uses this on the Code struct from the model layer. Originally Code and CodeBreaker sat in the same model file. As Code gained more logic, it deserved its own dedicated file. You could manually make a new Swift file and copy‑paste, but the refactor tool automates that safely.

Next he breaks out a UI piece: the peg drawing code inside the main view. The repeated rounded‑rectangle drawing logic gets pulled into a standalone PegView. The workflow is straightforward: copy the view code, make a new SwiftUI View template file, paste the drawing code, then add an incoming stored property to accept peg data. The preview canvas can supply sample peg data so you can see the component in isolation.

One habit he emphasises is using // MARK:‑ comments. These do two practical things. First, they draw a thin divider line in your source file. Second, they add clickable markers in Xcode’s jump‑to‑file bar. His personal discipline is marking two sections in every view: incoming data, and the view’s body. This creates consistent mental separation as you manage SwiftUI data flow. I found this part really practical; it’s a low‑effort habit that makes scanning larger SwiftUI files much easier.

He also points out a nice Xcode feature: pinning previews. When you jump between model files and view files, the preview pane often rebuilds and resizes. If you pin a preview, it stays visible while you edit other source files. This lets you tweak constants in one file and watch the UI update without constant switching back and forth.

Back in the model, he adds a reset() mutating function on the Code struct. The intended behaviour: after the user submits a guess, clear out the current guess pegs. All the logic lives in the model, not the view. Since SwiftUI’s UI is a reflection of model state, resetting model values automatically refreshes the screen, even picking up existing withAnimation animation wrappers.
 

Building the peg chooser and introducing selection state

Up to this point in Code‑Breaker, players tapped individual pegs to cycle through colours. That interaction was clunky. The instructor wants a dedicated colour‑selection keyboard at the bottom of the screen, called a PegChooser.

Before building the keyboard, a new piece of state is needed: a selection index. This integer tracks which peg position is currently active. When you tap a peg on‑screen, that index updates. When you tap a colour button in the chooser keyboard, it writes the chosen colour into whichever peg position matches the selection index.

This selection value belongs to the main CodeBreakerView, so it becomes a @State private var. Remember: @State marks data owned by this view, its single source of truth. Marking it private is standard practice.

He then adds a method inside the model: setGuessPeg(peg:at:). This is a mutating model function that safely updates a peg at a given array index. He uses a guard statement to check if the index falls within valid array bounds. If the index is out‑of‑range, the function simply returns early, avoiding a runtime crash. He explains guard as a defensive coding tool: it protects the rest of your function from bad inputs, and signals to readers what pre‑conditions must hold for the subsequent code to run.

With selection state in place, the UI needs visual feedback to show which peg is selected. He draws a light‑coloured background shape behind the selected peg. Trying opacity modifier created problems in dark mode; semi‑transparent layers would show whatever background sat underneath. To avoid opacity downsides, he creates a custom colour extension on SwiftUI’s Color type. The extension builds greys using hue‑saturation‑brightness initialiser, giving fully‑opaque light‑grey shades that work reliably in both light and dark appearance modes.

Magic numbers come up here. Hard‑coded padding values, corner radii and brightness floats scattered across view code hurt maintainability. If you later change layout for iPad or other devices, scattered numbers are hard to adjust. His preferred pattern: create nested structs inside your view, filled with static let constants. Group constants by purpose, for example a nested Selection struct for all values related to the selection highlight. This keeps magic numbers gathered in one spot, improves readability through descriptive names, and makes bulk tweaks simple. These nested constant structs live in the view file, but you could also move them out via extensions into separate files if your project grows very large.
 

@Binding: sharing source‑of‑truth across views

Now comes a major data‑flow lesson. He extracts the peg‑display loop from CodeBreakerView into a new CodeView. CodeView renders a whole row of pegs. Initially he copies the @State selection variable directly into CodeView. Once he runs the app, behaviour breaks.

The root cause: two separate @State variables. Each view owned its own independent copy of selection. Tapping pegs changed one value; operating the peg chooser changed the other. They never synchronised. There were two separate sources of truth for one piece of application state.

The fix is @Binding. Instead of owning its own state, CodeView accepts a @Binding var selection: Int. A binding does not hold the source‑of‑truth itself. It acts as a reference conduit pointing back to the source‑of‑truth owned elsewhere. The original @State variable stays in CodeBreakerView. When instantiating CodeView, you pass $selection — the dollar‑sign syntax generates a binding reference to your state variable.

Important rules he calls out:

• @Binding properties cannot be private.

 

• @Binding cannot have default initial values, because the source‑of‑truth lives outside.

 

• Use var for bindings, not let, because you might write through the binding.

 

• let incoming properties are for read‑only data flowing into a view.

He then shows a common anti‑pattern. When first creating PegChooser, he passes the entire model object (CodeBreaker) as a binding, plus also passes binding to selection. Functionally it worked, but it was bad design. The PegChooser only needs to know the list of available peg colours and to notify the parent when a colour gets selected. It does not need full read‑write access to the entire game model.

Good view design asks: what does this component semantically need to do its job? PegChooser just displays colour options and reports when user picks one. It should receive the colour options as read‑only input (let choices: [Peg]), and accept a closure callback onChoose: (Peg) -> Void? for events. The optional closure means you could even use PegChooser as a static display widget with no interaction. All the logic for updating guess peg and advancing selection stays back in the parent view. The child component only fires the callback and knows nothing about game rules.

This separation keeps views loosely coupled. You can reuse PegChooser elsewhere without dragging the whole CodeBreaker model type along. This is one of the most important takeaways for Assignment 3.
 

Hiding master code and new helper library for Assignment 3

With the data‑flow demo complete, he adds game logic to hide the master secret code. He modifies the model’s Code enum associated values so the master case carries an isHidden boolean. A computed property exposes this boolean. When the game ends (user guesses correctly), set isHidden to false to reveal the answer.

To detect game over he writes a computed isOver variable. It checks whether the last attempt’s pegs exactly match master code pegs. Since attempts.last returns optional, he demonstrates optional chaining syntax. If the attempts array is empty, .last becomes nil and the whole comparison evaluates to false.

Xcode sometimes gets into a broken build state after large source‑file changes, causing strange bad‑access runtime crashes. His troubleshooting tip: use Product → Clean Build Folder to wipe cached build artefacts and rebuild everything fresh.

Once the game ends, the input UI should disappear. SwiftUI ViewBuilder supports regular if statements inside body, so conditionally render the guess input UI only when the game is not over. Also reset selection index back to zero after submitting each guess.

The final segment previews Assignment 3. The assignment task is to implement a word‑guessing app. He provides a pre‑built Words helper class. It can load a word list over network, check whether a string is valid word, and return random words of given length. This helper injects itself into SwiftUI’s environment values. You declare @Environment(\.words) inside a view to get access to the instance.

One complication: the word list loads asynchronously over network. It is not ready immediately at app launch. He mentions the .onChange view modifier as the tool for reacting once the word count property changes. Until words finish loading you can fall back to a placeholder word. He notes the helper deals with networking errors and asynchronous logic, topics the course will cover in greater depth later.

One point that felt a little under‑explained: the environment‑injected Words class is a reference‑type (class), not value‑type struct. He skips over what implications that has for SwiftUI view invalidation. If you mutate internal state inside that class, SwiftUI won’t automatically know to refresh views unless you manually trigger updates. That detail is glossed over in the lecture; I would probably need to read the provided assignment code sample to fully grasp that part.

Assignment 3 is due one week after this lecture. It also requires adding animations, material for the next week’s class, hence the extended deadline.