Stanford CS193p： iOS Development with SwiftUI ｜ L9： Protocols — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CS193p: iOS Development with SwiftUI | 2025 | L9: Protocols

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 covers protocols, one of Swift's most powerful and pervasive language features. It explains how protocols define blueprints of methods, properties, and initializers that types can adopt, and how protocol-oriented programming enables flexible, composable code design. The lecture also covers protocol extensions, protocol inheritance, and associated types, and demonstrates how protocols are used throughout SwiftUI — from the View protocol itself to Identifiable, Equatable, and Hashable. It also introduces elapsed time tracking as a practical application of these concepts in the CodeBreaker app.

I just went through lecture nine of Stanford CS193p, which centers on Protocols. This session opened by walking through the quiz solution for the Codebreaker demo app, before moving on to building an elapsed‑time timer, and then diving deep into Swift’s protocol‑oriented programming ideas, covering Equatable, Hashable, and Identifiable. The lecturer also previewed what is coming in the next class and Assignment 4. These notes break down the demo work, core protocol concepts, and spots that felt confusing while listening.
 

Fixing the pop‑quiz animation bug in Codebreaker

The opening segment walked through resolving an annoying animation glitch in their in‑class Codebreaker game demo (1:19). After entering a guess and hitting restart, the old guess row would briefly fade out then fade back in, creating a flash effect. That flash was unwanted for normal game restarts, but the fade transition was actually intentional for one scenario: when the player had correctly solved the puzzle and the game finished.

The lecturer shared a practical debugging trick for SwiftUI animation issues: slow down your animation duration. If you crank up animation length, you get visible time to watch exactly what sequence of view changes is unfolding. That makes it far easier to trace which view is triggering unexpected animations. In this demo they swapped their bouncy animation out for an ease‑in‑out animation running for multiple seconds so they could visually track the disappearing and reappearing guess row.

At first glance you might think the fix is just to delete the opacity animation modifier entirely. The lecturer showed that removing it does eliminate the flash on restart, but breaks the desired behaviour for completed games. When you solve the puzzle, you rely on that opacity logic to stop UI elements from sliding and overlapping awkwardly. Removing the modifier took away that critical behaviour.

The straightforward correct fix was to gate the opacity‑driven animation logic. Only run that special fade‑out and slide‑down behaviour when the game state shows the player has already solved the puzzle. If the game is still ongoing, restarting skips that whole animation pathway.

There was a second, more refined approach the lecturer liked better. Instead of adding conditional checks directly on the view, you conditionally trigger the restarting state variable. You only set restarting = true when the game has actually ended. If players restart an unfinished game, you never activate that state variable at all. This meant they could even delete some of the offset/slide‑down animation logic entirely, since the conditional state prevented conflicting view updates. Even though the slide‑down visual was optional, the lecturer noted you could keep it if you liked the aesthetic.

During this demo segment, there was a student question about sizing UI elements consistently. The lecturer issued a strong warning about using fixed width and height parameters on the frame modifier. Hard‑coding fixed dimensions will break your app on different hardware, especially iPad, which is a requirement for Assignment four. Your UI should adapt and stretch to fill whatever screen real estate it gets.

For making buttons or other items keep uniform proportions across screen sizes, they recommended leaning on aspectRatio. Hidden spacer‑style views that consume layout space are another workaround. The lecturer mentioned GeometryReader exists, but asked students to avoid it for assignments. They wanted learners to practice adaptive layout fundamentals first, even though GeometryReader could technically solve sizing problems.
 

Building an elapsed‑time timer view

After wrapping up the animation quiz fix, the lecture shifted to implementing an elapsed‑time stopwatch view for Codebreaker, to track how long players spent on each game (12:22).
The lecturer emphasized separating concerns: all time‑tracking logic lives inside the model, not the SwiftUI view. The UI only displays values calculated by the model. Inside the Codebreaker model struct, two new properties get added. A startTime of type Date marks when the game begins, and an optional endTime. The endTime is optional because when a game is running, the ending timestamp does not exist yet.

When the player successfully guesses the code and finishes the game, assign endTime = Date.now. Every time the user restarts the game, reset startTime to the current moment and set endTime back to nil.

Next they built a standalone ElapsedTime SwiftUI view. This view takes two inputs: a non‑optional start Date, and an optional end Date. Inside the view body they use if‑let optional unwrapping on endTime. If endTime has a value, format the time offset between start and end. If endTime remains nil, calculate the offset from start time against the current moment.
This is where a key gotcha showed up. Simply writing Date.now directly inside the view body does not create a live‑updating timer. Date.now evaluates once when SwiftUI recomputes body. The view will not refresh repeatedly just because wall‑clock time passes. The lecturer introduced a special time data source that tells the Text view to continuously refresh its displayed offset value, making the counter tick live while the game is active.

Styling the timer brought more small SwiftUI tips. They applied a flexible font modifier so the text expands to fill available space. Then monospaced() to stop numbers from shifting width as digits change. Without monospaced fonts, different numeral widths cause the whole text block to jitter as seconds tick by. A lineLimit(1) keeps the formatted time string from wrapping onto multiple lines. The lecturer commented out this finished timer for the rest of their demo to avoid visual clutter.
 

Swift protocols: core ideas and three key system protocols

This is the longest section of the lecture, diving into Swift’s protocol‑oriented design (26:44). A protocol acts like a blueprint. It lists required variables and function signatures, but includes zero concrete implementation code. Variables in a protocol only specify get or get set access requirements. Functions in a protocol list names, parameters and return types, no function bodies.

Protocols serve four main purposes. First, they act as a contract across different sections of your code, defining exactly what capabilities a conforming type guarantees. Second, they enable shared code through extensions. You can write an extension on a protocol, adding implemented methods. Every type that conforms automatically gains that functionality. This is exactly how every SwiftUI View gets all its view modifiers. Apple wrote extensions on the View protocol to supply .font(), .padding() and many others.

Third, protocols can be used as types. This brings us to some and any. some hides a concrete type from one side of the code, but the compiler still knows the exact underlying type at compile time. var body: some View is the most common example. The caller only knows it is some View; Swift knows exactly which view type is returned.

By contrast any erases type information completely. Resolution happens at runtime through boxing. It has performance overhead. The lecturer strongly discouraged students from reaching for any casually. For class assignments, they joked you should ask permission before you use any. SwiftUI’s ViewBuilder avoids any View entirely, by building strongly‑typed view tuples for you.

Fourth is constraints and gains. You constrain generic types to conform to a protocol, which unlocks extra functionality. Dictionaries are a perfect real‑world example: dictionary keys must conform to Hashable. The generic dictionary does not care what your key type is, but it requires the hash‑related capabilities so it can operate as a hash table.

Then the lecture walked through three foundational protocols: Equatable, Hashable, Identifiable.

Equatable gives you the == operator. The double‑equals operator is not baked into Swift language syntax. It is just a static function defined by the Equatable protocol. Many types get automatic synthesis of Equatable. For structs, all stored properties must themselves be Equatable. For enums without associated values you get conformance for free. Enums with associated data get synthesized implementation only if every piece of associated data conforms.

You can manually implement the static == function when synthesis won’t work. The lecturer gave an important word of warning. SwiftUI uses Equatable to decide whether state has changed, to avoid unnecessary view body recomputation. If you write a custom Equatable conformance, your equality logic must truly represent whether your model instance is fully identical. If you ignore some properties in your equality check, SwiftUI will miss legitimate state changes. The lecturer also noted you should not blindly make every model struct Equatable. SwiftUI can detect mutations on value types through mutating functions even without Equatable.

Hashable inherits from Equatable. That makes logical sense: if two items are equal, they must produce the same hash value. Unequal items are allowed to collide and share a hash value. You implement hash(into:) feeding your relevant properties into the hasher object. Like Equatable, Hashable synthesis works for structs and enums when all stored properties conform to Hashable. The lecturer touched briefly on inout parameters here, noting students would rarely need to write them.

Identifiable exists primarily for SwiftUI’s ForEach. ForEach needs stable, unique, hashable identifiers to match model data to on‑screen views. This keeps animations working when collections reorder, add or remove elements.

There are multiple ways to supply identifiers for ForEach. You can point the id: argument at one of your struct’s properties. Or make your type conform to Identifiable, which requires an id property. The associatedtype ID inside Identifiable lets your id property be any Hashable type you choose.

One common pitfall is using array indices as identifiers. Indices are guaranteed unique and hashable, but they are not stable. If you reorder items or insert items in the middle of your array, indices shift and break ForEach animations. Indices only work safely when you exclusively append or delete from the very end of your array.

When implementing Identifiable, first try to derive an id from your existing stored properties. Only as a last resort generate artificial unique values such as UUID. Classes automatically get synthesized Identifiable conformance, because class instances have built‑in reference identity.

Towards the end the lecturer shifted to classes and @Observable. Structs are value types; classes are reference types. SwiftUI does not use class inheritance much, but leverages reference semantics. The big catch: Swift cannot automatically detect when you mutate a class instance. To fix this, mark your model class with the @Observable macro. This macro generates hidden boilerplate so SwiftUI can observe changes to class properties and refresh the UI.
 

One confusing or unresolved point from the lecture

I found the distinction between some and any hard to fully grasp just from this verbal explanation. The lecturer explained compile‑time versus runtime type resolution, but there were no concrete side‑by‑side code snippets shown during the lecture. It is easy to intellectually know any carries runtime overhead, but less clear exactly what scenarios would push you to pick any even with that cost. The lecturer mostly just told students avoid it, without walking through a valid use‑case example. It would help to see small code samples contrasting both keywords.
 

Upcoming course work preview

The lecture wrapped without finishing the planned live demo for Equatable, Hashable, Identifiable. That demo will open the next class session.

Looking ahead, they are going to rebuild the Codebreaker app. Instead of launching straight into one game, the root screen will show a list of different Codebreaker game instances. Users will create new games, browse past games, delete old entries, and see metadata like how long each game took. This work will span two class meetings.

Assignment four will be released on the Wednesday following this lecture. It will require supporting iPad layouts. The due date is pushed out to give students time to absorb all the new material about classes and @Observable. Many ideas shown in the coming demos will also be useful for finishing Assignment three.