Stanford CS193p: iOS Development with SwiftUI | 2025 | L10: Building Complex UIs

Key Concepts

• ForEach Identifiers: The importance of unique, stable, and Hashable identifiers for elements in a ForEach loop.
• Hashable Protocol: Conforming types to Hashable to allow for synthesized conformance and use as unique identifiers.
• Identifiable Protocol: Conforming types to Identifiable to automatically provide an id property for use in SwiftUI views.
• List View: A powerful SwiftUI container for displaying scrollable lists of data, combining VStack, ScrollView, Divider, and ForEach.
• NavigationStack: A container that enables navigation between views, providing a navigation bar and back button.
• NavigationLink: A view that allows users to navigate to another view when tapped.
• @Binding: A property wrapper used to create a two-way connection between a view and a source of truth, allowing for data modification.
• Classes vs. Structs: Differences in mutability, identity, and how they are passed around in SwiftUI.
• @Observable: A property wrapper for classes that makes them observable by SwiftUI, enabling automatic UI updates when data changes.
• Toolbar and ToolbarItem: Modifiers for adding buttons and other views to the navigation bar.
• Semantic vs. Physical Placement: Using semantic placements like .primaryAction and .automatic for toolbar items to let SwiftUI decide the best position.
• NavigationDestination: A modifier used with NavigationLink to specify which view to display for a given data type.

ForEach Identifiers and Protocol Conformance

The lecture begins by refining the use of ForEach in SwiftUI. Initially, the code used indices to iterate over a reversed array of attempts. This was refactored to iterate directly over the attempt objects by removing .indices. This change necessitates ensuring that the attempt object (specifically the Code struct) is suitable as a unique identifier.

Key Points:

• Identifier Requirements: For ForEach to work correctly, the identifier used must be unique within the collection, stable over time, and Hashable.
• .self as Identifier: Using \.self as the identifier for ForEach requires the element itself to be Hashable.
• Code Struct and Hashability: The Code struct was initially not Hashable. To make it Hashable, its nested Kind enum also needed to conform to Hashable. Swift can synthesize Hashable conformance for enums with no associated data or enums where all associated data is Hashable.
• Uniqueness of Attempts: The lecture emphasizes that while Code can be made Hashable, the uniqueness requirement for ForEach is crucial. The code was updated to prevent duplicate guesses (attempts with the same pegs) to ensure uniqueness.
• Stability of Identifiers: The pegs of an attempt are considered stable because they cannot be changed after an attempt is made.
• \.pegs as Identifier: The speaker then argues that \.pegs is a more appropriate and simpler unique, stable, and Hashable identifier for an attempt than \.self. This negates the need to make Code itself Hashable for this specific ForEach usage.
• Identifiable Protocol: The concept of conforming to the Identifiable protocol is introduced. If a type conforms to Identifiable, SwiftUI can automatically use its id property as the identifier for ForEach, eliminating the need for id: \.someProperty.
• Synthesizing Identifiable: Swift can synthesize Identifiable conformance for classes but not typically for structs because structs lack inherent identity. For structs, a unique id must be manually provided. The ObjectIdentifier is mentioned as a placeholder, but the pegs computed property was used as the actual id for the Code struct.
• Choosing Identifiers: The speaker advises against making Code conform to Identifiable if its identity is not semantically clear in all contexts. Using id: \.pegs is preferred for clarity when pegs are the definitive unique identifier for an attempt.

Enhancing the App with Multiple Games and Navigation

The lecture then shifts to expanding the app's functionality to support multiple game instances and user navigation between them.

Main Topics and Key Points:

• GameChooser View: A new root view (GameChooser) is introduced to manage a list of available games. This replaces the previous CodeBreakerView as the app's entry point.
• List View: The List view is presented as a powerful and fundamental SwiftUI component for displaying collections of data. It's described as a combination of VStack, ScrollView, Divider, and ForEach.
• Game Data Management: A @State private var games array is used within GameChooser to hold the game data. The speaker notes that for more complex apps, this data might reside in a higher level or be persisted.
• Displaying Games in a List: The List view is initialized with the games array and uses \.pegChoices as the identifier for each game.
• PegChooser for Game Representation: The existing PegChooser view is repurposed to display a summary of each game's pegChoices within the list. The optional onChoose closure of PegChooser is left unimplemented to prevent user interaction with the pegs in the list view.
• Populating the Game List: The onAppear modifier is used to populate the games array with sample CodeBreaker instances, including "Mastermind," "Earth Tones," and "Bluish Tones."
• Game Naming: The CodeBreaker model is extended with a name property to allow games to be named. This name is then displayed alongside the PegChooser in the GameChooser list using a VStack.
• Styling and Layout: Basic styling is applied to the GameChooser list, including .font(.title) for the game name and .frame(maxHeight: 50) to limit the height of list items. The speaker cautions against using fixed width and height with frame, advocating for maxHeight or maxWidth for flexibility.
• Pluralization with inflection: A demonstration of Swift's morphology mechanism (inflection) is shown to handle pluralization correctly in different languages, avoiding simple English-based ternary expressions for "attempt" vs. "attempts."
• List Customization: Various .list view modifiers are mentioned, including .listStyle() (e.g., .plain, .group), .listItemTint(), and .listRowInsets(). Modifiers like .listRowSeparator(.hidden) can be applied to individual rows.
• GameSummary View: The content of each row in the GameChooser list is extracted into a separate "helicopter view" called GameSummary for better organization.
• #Preview for GameSummary: The #Preview for GameSummary is enhanced to include it within a List to better visualize its appearance in context.
• Sections in Lists: The lecture demonstrates how to divide a List into sections using the Section view, which can have headers. This requires manually implementing the ForEach within the List to allow for sectioning.
• Navigation with NavigationLink and NavigationStack:
  • NavigationLink is used to wrap the GameSummary view, enabling navigation to another view when tapped.
  • Navigation only works within the context of a NavigationStack.
  • The CodeBreakerView was modified to accept a Binding<CodeBreaker> to allow for shared state and updates (e.g., attempt count).
  • The List initializer was updated to use the $ prefix for its elements ($games) to enable binding to the items within the list.
  • The CodeBreakerView's preview was updated to use @State and @Previewable to provide a binding for the preview.
• Edit Actions and Toolbar:
  • The List with $games supports editActions like .delete and .move.
  • An EditButton is introduced, typically placed in a toolbar using the .toolbar modifier, to enable editing mode for the list.
  • The NavigationStack is responsible for displaying toolbars. Toolbars are associated with the currently visible view within the NavigationStack.
  • Toolbar items can be placed using semantic placements like .primaryAction and .automatic to let SwiftUI manage their positioning.
• Classes as Models (@Observable):
  • The CodeBreaker struct was converted to a class to explore reference type behavior.
  • Classes are inherently mutable, so the mutating keyword is removed from functions.
  • When a class is used as a model, it needs to be marked with @Observable to enable SwiftUI to observe changes and update the UI. Without @Observable, UI updates would not occur when the class's properties are modified.
  • @State works with classes, storing a reference to the object in the heap.
  • editActions (delete and move) are not directly supported by List when using classes passed by reference. Instead, .onDelete and .onMove modifiers are applied to the ForEach loop.
  • Classes, being reference types, have a strong sense of identity and can easily conform to Identifiable (often synthesized).
  • navigationDestination for Classes: When using classes with NavigationLink, a more efficient approach is to use NavigationLink(value: game) and then specify the destination view using .navigationDestination(for: CodeBreaker.self) { game in CodeBreakerView(game: game) }. This defers the creation of the destination view until navigation occurs.
  • Hashability for navigationDestination: For navigationDestination to work with custom types, those types must conform to Hashable. This requires them to also conform to Equatable. For classes, equality is typically checked by comparing their id property.
  • Extensions for Protocol Conformance: Protocol conformance (like Identifiable, Equatable, Hashable) for classes can be placed in extensions to keep the main class definition cleaner.
• Multiple NavigationLink Values and Destinations: The lecture demonstrates how to have multiple NavigationLinks within a list, each with a different value type, and how to use .navigationDestination to specify different views for each value type (e.g., navigating to show pegs from a master code).

Future Outlook

• iPad and Mac Support: The next lecture will focus on adapting the app for iPad and Mac.
• Game Creation and Editing: Functionality for creating new games and editing existing ones will be implemented.
• Persistence: Data persistence (saving game state) will be addressed in a later assignment (A5).

Conclusion

This lecture provided a deep dive into essential SwiftUI concepts for building more complex applications. It covered the nuances of ForEach identifiers, protocol conformance (Hashable, Identifiable), advanced List and navigation patterns (NavigationStack, NavigationLink, navigationDestination), and the implications of using classes as models with @Observable. The emphasis was on understanding the underlying mechanisms and making informed design choices for clarity, efficiency, and maintainability.