SwiftUI Code Refactoring and Data Flow in Practice

One. Course Details

This is the sixth lecture of Stanford University's CS193p iOS Application Development course for Spring 2025, taught by Paul Hegarty. The entire session is dedicated to hands-on Xcode demo work, putting the data flow concepts from Lecture 5 into practice through iterative code refactoring and view decomposition.

The lecture walks students through extracting views into separate files, managing constants cleanly, implementing proper state sharing with @Binding, and designing semantic view interfaces. It concludes with an introduction to Assignment 3, a word-based guessing game similar to Wordle, and provides a helper library for dictionary access and random word generation.

The next lecture will cover SwiftUI animation systems, which is required for the final task of Assignment 3. The complete working CodeBreaker code from this lecture is published on Canvas for students to reference.

Two. Key Learning Takeaways

Extract related types and views into separate files using Xcode's Refactor -> Extract [Selection] to File feature to keep code organized and maintainable.

Use // MARK: comments to divide code into logical sections, improving readability and navigation within files.

Manage magic numbers by grouping them into nested constant structs, providing clear namespacing and self-documenting code.

@Binding creates a read-write connection to state owned by a parent view, enabling safe two-way state sharing without duplicating sources of truth.

Never pass your entire Model to child views; instead, pass only the specific data they need and use callback functions for actions.

The guard statement validates preconditions at the start of functions, improving code readability and preventing early exits on invalid input.

Optional chaining (?.) safely accesses properties and methods on optional values, returning nil immediately if any link in the chain is nil.

Design view interfaces around their semantic purpose, not around the implementation details of where they will be used.

Clean build folders are the first step in debugging mysterious EXC_BAD_ACCESS errors caused by corrupted build artifacts.

Three. Course Gold Quotes

"It's all about naming in computer science. Good names on functions, good names on variables, good names on constants — that's the best documentation you can write." "@Binding is a tool, not a solution. Just because you can pass a Binding doesn't mean you should pass your entire Model to every view." "A good view interface only asks for the information it actually needs to do its job. Nothing more, nothing less." "Magic numbers scattered throughout your code are a code smell. Gather them all in one place so you can see them and question whether they're really necessary." "// MARK: comments aren't just for decoration. They force you to think about how your code is structured and how data flows through it." "The best views are reusable and self-contained. They shouldn't know anything about the rest of your app."

Four. Layered Learning Notes

Module 1: Code Organization and View Decomposition

Maintaining clean code structure is essential as applications grow in complexity. The lecture demonstrates three key refactoring techniques:

1. Extract types to separate files: Use Xcode's refactoring tools to move related types (like the Code struct) into their own files. This keeps individual files focused and makes it easier to find code.

2. Decompose large views into smaller "helicopter views": Break down monolithic views into smaller, reusable components with clear responsibilities:

   • PegView: Draws a single game peg

   • CodeView: Draws a complete 4-peg code with selection support

   • PegChooser: Draws the keyboard of available peg choices

3. Use // MARK: comments to section code: Standardize code organization with consistent section headers:

   • // MARK: - Data In for read-only properties passed into the view

   • // MARK: - Data Owned for @State properties

   • // MARK: - Data Shared for @Binding properties

   • // MARK: - Data Out Function for callback functions

   • // MARK: - Body for the view's main body

This decomposition makes code more readable, reusable, and easier to debug. Each view has a single, clear responsibility, and changes to one component have minimal impact on others.

Module 2: Clean Constant Management

Magic numbers (hardcoded numeric values scattered throughout code) make applications difficult to maintain and adapt to different screen sizes. The lecture demonstrates a clean approach to managing constants using nested structs:
swift

private struct Selection {
    static let border: CGFloat = 5
    static let cornerRadius: CGFloat = 10
    static let color = Color.gray(brightness: 0.85)
}

Key benefits of this approach:

• Namespacing: Constants are grouped by their purpose, avoiding naming conflicts

• Self-documentation: Clear names like Selection.border explain what the constant represents

• Single source of truth: Changing a constant in one place updates all uses throughout the view

• Easy adaptation: All constants are visible in one place, making it simple to adjust values for different platforms or design changes

Module 3: @Binding and State Sharing

When decomposing views, you often need to share mutable state between parent and child views. @Binding is the tool for this job:

• Parent view: Owns the source of truth with @State private var selection = 0

• Child view: Declares @Binding var selection: Int to receive a reference to the parent's state

• Passing the binding: Use the $ prefix to pass a binding from parent to child: CodeView(code: code, selection: $selection)

Critical rules for using @Binding:

• Never mark @Binding as private: It needs to be accessible from the parent view that creates it

• Never provide an initial value for @Binding: The parent owns the state and provides the value

• Only use @Binding for mutable state: If the child only needs to read the value, pass it as a regular let property

A common anti-pattern demonstrated in the lecture is passing an entire Model object as a @Binding to a child view. This creates tight coupling between views and gives child views access to far more state than they need.

Module 4: Semantic View Interface Design

The most important principle demonstrated in this lecture is designing view interfaces around their semantic purpose, not around implementation details. For the PegChooser view:

• Bad interface: @Binding var game: CodeBreaker, @Binding var selection: Int

• Good interface: let choices: [Peg], let onChoose: ((Peg) -> Void)?

The good interface clearly expresses what the view does: it displays a list of choices and calls a callback when one is selected. It knows nothing about CodeBreaker games or selections, making it completely reusable in any context where you need to choose from a list of pegs.

This approach follows the single responsibility principle and creates loose coupling between components. Parent views handle the business logic of what happens when a peg is chosen, while child views focus solely on presentation.

Module 5: Swift Language Features in Practice

The lecture introduces several important Swift language features in a real-world context:

1. guard statement: Validates preconditions at the start of functions, providing an early exit if conditions are not met:
   swift

   mutating func setGuessPeg(_ peg: Peg, at index: Int) {
       guard guess.pegs.indices.contains(index) else { return }
       guess.pegs[index] = peg
   }
   

2. Optional chaining: Safely accesses properties on optional values without explicit unwrapping:
   swift

   var isOver: Bool {
       attempts.last?.pegs == masterCode.pegs
   }
   

3. Optional functions: Functions can be optional, and you call them with a ? to do nothing if they are nil:
   swift

   let onChoose: ((Peg) -> Void)?
   // ...
   onChoose?(peg)
   

4. Custom environment values: Extend EnvironmentValues to add app-specific global state, like the dictionary helper for Assignment 3.

Module 6: Assignment 3 Introduction

Assignment 3 challenges students to build a word-based guessing game similar to Wordle. Key requirements include:

• 5-letter word guesses

• Validation that guesses are real English words

• Color-coded feedback for correct letters in the correct position, correct letters in the wrong position, and incorrect letters

• Smooth animations for game interactions

The lecture provides a Words.swift helper library that:

• Loads a dictionary of English words from the internet

• Provides a contains(word:) method to validate guesses

• Provides a randomWord(ofLength:) method to generate secret words

• Exposes itself as a custom environment value for easy access throughout the app

Students will use the onChange(of:) view modifier to wait for the dictionary to load before starting the game.

May you build clean, well-architected SwiftUI applications as you continue your iOS development journey. May your view decompositions be logical, your state sharing be bug-free, and your Assignment 3 word game turn out perfectly with beautiful animations. Good luck and happy coding!