Even More Complex UIs — Annotated Lecture Notes & Key Takeaways

These notes cover  lecture 12, which focuses on building more complex UIs in SwiftUI. Almost the entire session is live coding. The instructor walks through refactoring view components, presenting modal sheets, building validation logic, responding to app state changes, and creating custom view modifiers. A big theme running through L12 is clean code organization — figuring out how to split large blocks of UI code into smaller, reusable pieces without introducing bugs.
 

Refactoring Views and Building Reusable Controls

The lecture opens with work on the existing Codebreaker game‑building app. The app has a game list screen with a plus button. Tapping the plus creates a new untitled game entry, but right now users cannot immediately edit that new game. The instructor’s goal is to pop up an editor right after pressing plus.

Before jumping to the sheet presentation, the instructor first pulls a subsection of the game editor out into its own standalone view called PegChoicesChooser. This view manages the list of peg color options. The reasoning here is straightforward: the main game editor should not own every piece of nested UI. Isolating this sub‑view makes previewing easier and keeps responsibilities narrow (1:00‑3:00).

A key point gets clarified here: the difference between @Binding and @Bindable. @Binding is used for struct value‑type data passed between views. @Bindable works with reference‑type ObservableObject classes, letting you generate a $ binding to mutate the observed model. The instructor emphasizes a good habit: avoid passing an entire model object into a sub‑view if only one property is needed. For PegChoicesChooser, only the array of pegs is passed, not the whole game object.

Inside this new view, they implement add and remove peg buttons. The initial implementation uses standard SwiftUI buttons, but the visuals are poor. Button labels wrap onto new lines, and all buttons show the default system blue tint. To fix this, the instructor builds a custom button helper that accepts a title, system image name, optional tint color, and an action closure.

One small Swift detail comes up. The action closure for the custom button needs @escaping because the closure will get stored and run later when the user taps, instead of executing immediately during view construction. They also use the tint() view modifier to apply custom coloring. Green tint goes to add, red tint to delete. All button actions get wrapped inside withAnimation so inserting and deleting list rows animates smoothly (6:00‑10:00).

Preview setup for this new component also gets attention. For previews to work with bindings, they create a local @State variable. Since the preview needs direct access to that state variable, the property uses @Previewable and cannot be marked private. They also add an onChange modifier inside the preview to print changes to peg choices, so they can verify edits are working in the preview canvas without running the full app.
 

Presenting modals with Sheet, Dismiss, and Toolbars

Once the peg chooser component is working, the lecture shifts to the plus‑button workflow. Originally, tapping plus would directly append a new game to the list. That approach is flawed. Users should edit before the game lands in the list, not edit after an untitled entry is already there. The right tool for this job is the SwiftUI sheet modifier for modal presentation (11:00‑14:00).

NavigationLinks are not appropriate here. Navigation pushes a new screen onto a stack, and users can freely move back and forth. A sheet is modal. It demands immediate user attention. The sheet renders differently depending on hardware: on iPhone it slides up from the bottom covering most of the screen; on iPad it appears as a floating centered rectangle. Sheets can be dismissed by a downward swipe gesture by default.

A sheet takes a binding to a boolean isPresented value. When true, sheet appears; when false, sheet disappears. Sheets animate automatically. You do not need to wrap state changes in withAnimation to trigger the sheet transition.

The instructor starts with a simple boolean @State variable showGameEditor. Then they realize they need to track which game object is being edited. They switch to an optional game object gameToEdit. If this optional is non‑nil, the sheet should show.

Initially they use onChange(of:) to sync gameToEdit to the boolean presentation state. When gameToEdit becomes non‑nil, set showGameEditor to true. When it becomes nil, set it false. They also use sheet’s onDismiss callback to clean up state when the sheet closes.

One complication emerges. gameToEdit is optional, but the GameEditor view expects a non‑optional game argument. Inside the sheet’s view‑builder they use if‑let conditional unwrapping. The instructor notes that force‑unwrapping (!) could work during development but should be avoided for shipping code. If the optional were nil, the sheet would render empty content, which is a bad user experience.

Next, they add toolbar buttons inside the sheet for Cancel and Done. Toolbar items only show up inside a NavigationStack, so they embed the GameEditor inside one even though they are not doing actual navigation. They use ToolbarItem with semantic placements: .cancellationAction for Cancel and .confirmationAction for Done. SwiftUI automatically positions Cancel to the left and bolds Done on the right side.

Rather than keep all the sheet‑related logic in the parent game‑list view, they refactor behavior down into GameEditor. They add a callback closure parameter onChoose that runs when the user taps Done. Inside the editor they use the environment value @Environment(\.dismiss). Calling this dismiss function closes the sheet from within the modal view itself. This removes some of the state‑sync burden from the parent view.

This refactoring makes the game‑list view code much cleaner. The parent no longer needs to know toolbar logic or dismissal mechanics. It just provides a game object and reacts to the completion callback.
 

Validation, Alerts, and handling edit‑existing‑game case

Now they want to prevent users from saving invalid game configurations. A valid game must have a non‑empty name and at least two distinct peg color options.

The instructor points out an interesting design scenario. Sometimes you cannot or do not want to add validation logic to your model. Reasons might include: you do not own the source code for the model library, or validation logic relies on UI‑framework types that should not live in the model layer. In this case they write a computed isValid property as an extension on the model, treated as UI‑layer code.

Two approaches for bad input get demonstrated. The first is disabling the Done button using the .disabled() modifier. The instructor thinks this is not great UX. Users get confused when a button is greyed out with zero feedback explaining why it is disabled.

The better approach shown is keeping Done enabled. When tapped, check validity programmatically. If invalid, pop up an alert. Alerts work similarly to sheets: they are view modifiers bound to a boolean presentation state. The alert displays a title, descriptive message, and confirmation button. The alert explains exactly what requirements are not satisfied, so users know what needs fixing (34:00‑41:00).

Then they add an edit action for pre‑existing games. Originally they put this in a context menu (long press). Later they add swipe actions (.swipeActions) for the leading edge of list rows. A caveat is mentioned: swipe actions do not work on macOS, so context menus remain necessary for cross‑platform compatibility.

A tricky bug surfaces when editing an existing game. Because Codebreaker is a class (reference type), passing the real game object into the editor means all edits mutate the original immediately. If the user taps Cancel, changes are already applied, which is wrong.

The fix is creating a manual copy of the game object before opening the editor. When Done is tapped, check whether this game already exists in the games list. If it is a brand‑new game, insert the copy to the top of the list. If editing an existing entry, find its index and replace the original object with the edited copy. Cancel simply dismisses, discarding the copy with zero changes to the source data. Making the copy manually is straightforward here since the model only has a couple properties. For much more complex classes you would want a dedicated copy method.
This copy also has a nice side‑effect: editing resets game progress like attempt history automatically.
 

Advanced Swift: Custom Binding, Timers and View Modifiers

This section is marked as advanced Swift content. The instructor says viewers who get confused can skip it without hurting their ability to complete assignments.

Right now there are two pieces of state: optional gameToEdit and boolean showGameEditor. These two variables represent the same logical state, which creates maintenance overhead. They show how to construct a custom Binding using the get and set closure initializer.

The binding’s get returns gameToEdit != nil. The set only responds to being set to false (dismiss case), setting gameToEdit = nil. Setting the binding to true is ignored because there is no meaningful value to assign. This eliminates the separate boolean state variable and removes the need for the onChange sync and some onDismiss logic (48:00‑54:00).

I found this part a bit hard to follow. Custom bindings are abstract. The value you read is derived from another variable, but writing only works in one direction. The lecture works, but I think this section would benefit from a separate small playground example to reinforce how get‑set bindings behave.

The lecture then moves to fixing broken elapsed‑time tracking in the game. The original timer starts the moment game objects initialize. In a split‑view iPad interface multiple games would count time simultaneously even when not being played. On iPhone, navigation changes trigger onAppear / onDisappear, but on iPad split view, views stay in memory and do not disappear when selection changes. So onAppear / onDisappear alone cannot reliably start and pause timers.

They add model methods startTimer() and pauseTimer(). Inside the model they store:

• optional startTime: Date?

• accumulated elapsedTime: TimeInterval

When pausing, calculate how much time passed since startTime, add it to elapsedTime, then set startTime back to nil. When starting, assign current date to startTime. Restarting a game resets both values. When the game finishes, the timer pauses automatically.

For iPad selection changes, they use onChange(of: game) with both old and new value parameters. When the selected game changes, pause the old game’s timer and start the new game’s timer.

Even that is not enough. If the whole app goes to the background, timers need to pause. They introduce the @Environment(\.scenePhase) environment variable. scenePhase can be .active, .inactive, .background. Using onChange(of: scenePhase), pause timers when moving to background and resume when becoming active. .inactive transitional state gets ignored.

All this timer‑tracking logic clutters up the game view body. To clean it up they demonstrate building a formal custom ViewModifier. A ViewModifier struct has a body(content: Content) method. The content parameter represents whatever view the modifier attaches to. The modifier can access environment values like scenePhase, then apply any number of view modifiers to content. They then add a convenience method on View so you can write something like .trackElapsedTime(inGame: game) instead of instantiating the modifier struct directly.

One limitation the lecturer points out: the scenePhase transition to .inactive does not trigger timer changes, so timing will have small inaccuracies during app state transitions. They accept this as acceptable trade‑off for practical code.

The lecture closes by previewing the next week’s material: SwiftData persistence.