Stanford CS193p： iOS Development with SwiftUI ｜ L11： iPad and Mac — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CS193p: iOS Development with SwiftUI | 2025 | L11: iPad and Mac

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 addresses adapting iOS applications for larger screen sizes and multiple Apple platforms. It covers adaptive layout techniques using GeometryReader and size classes, split view and sidebar navigation for iPad, and how SwiftUI's declarative model enables the same codebase to run on iOS, iPadOS, and macOS with minimal modification. The lecture also discusses platform-specific considerations including pointer support, keyboard shortcuts, window management, and the design patterns that make apps feel native on each device.

These notes cover lecture 11 of Stanford CS193p, focused on cross‑platform SwiftUI development for iPad and Mac. A huge portion of this session centers on NavigationSplitView, along with view refactoring, selection state management, context menus, and building a form‑based game editor. The lecturer warned upfront that the lesson would end mid‑task, and we would pick up unfinished work in the next class. The keyword here is cross‑platform SwiftUI, which threads through nearly every demo and code change shown in this session.
 

Adapting iPhone‑built apps for iPad with NavigationSplitView

The lecturer opened by showing what happens when you simply enable iPad support for an iPhone app without any layout adjustments. The UI blows up to fill the large iPad screen, elements become oversized, and you waste most of the available display real estate. This is a common pitfall for new SwiftUI developers. The fix demonstrated was swapping out NavigationStack for NavigationSplitView.

To draw a quick mental comparison: NavigationStack works like a deck of cards. Every NavigationLink pushes a new view card on top, and the back button pops it back off. This is the standard iPhone navigation pattern. NavigationSplitView divides the screen into up to three panes: a left sidebar, optional middle content pane, and a right detail pane. In their Codebreaker demo they only used two panes, sidebar for the game list and detail for the active game.

When you first drop in a NavigationSplitView you will hit a compile error. Unlike NavigationStack, it expects content for your detail pane. For the initial empty state, they put simple placeholder text prompting users to pick a game.

Even after getting the basic two‑panel layout rendering, there was a usability snag. By default, the sidebar can get hidden, and tapping list items would hide one pane to show the other. The lecturer introduced the .navigationSplitViewStyle(.balanced) modifier to divide screen space between both panes. This keeps both views visible simultaneously on larger displays.
Next came controlling initial pane visibility. You can bind columnVisibility to control which panes show on launch. One interesting trick they walked through was using a constant binding set to .all. This tells SwiftUI you want all panes shown on startup, while still letting users manually collapse or expand panes via the UI. You do not need a dedicated @State variable if you don’t intend to programmatically override user‑triggered visibility changes.

One point that was hard to follow here is how SwiftUI automatically switches behaviour based on horizontal size classes, not strictly device type (16:30). On horizontally compact environments, like most iPhones, NavigationSplitView behaves exactly like a regular NavigationStack, pushing views full‑screen. On regular horizontal size classes, like iPad or large iPhones in landscape, it renders as multi‑column split view. You do not need to write conditional code checking for iPad versus iPhone. The lecturer actively discouraged writing device‑specific if checks unless you have very particular edge‑case needs.

They also touched on responsive sizing best practices. Hard‑coding fixed frame heights or widths is discouraged. Instead, use .frame(maxHeight:) or .frame(maxWidth:) to set upper bounds while still letting views expand when space permits. Magic number constants get pulled out into struct‑stored constants for easier future tweaks.

Navigation titles also work across both navigation containers. You attach .navigationTitle() to your sub‑views. The navigation system reads this value and renders it in the navigation bar. There is also .navigationTitleDisplayMode(.inline) to shrink large titles and keep them inside the navigation bar rather than taking up extra vertical screen space.
 

Managing explicit list selection state

Once they switched to NavigationSplitView, they hit a new problem. The built‑in implicit list selection stops working once you want to react programmatically to what item the user tapped. You have to create your own optional @State variable to hold the selected model object.

When you pass a selection binding into a List, each NavigationLink with a value parameter will automatically update this binding when tapped. Conversely, if you manually set your selection state in code, the list will treat that as if the user tapped that entry.

This changes how you construct your detail pane. You can no longer rely solely on navigationDestination. Inside the detail builder closure you use optional binding on your selection state. If something is selected, render the corresponding game view. If nothing is selected, show the placeholder “choose a game” text.

This gives you power to set an initial selected item when the app launches. You can pre‑select the first list entry, the last entry, or even a random entry on startup. There was an interesting behaviour note for iPhone: on compact horizontal sizes, this pre‑selection would push the detail view open immediately on launch. The lecturer noted this might not be ideal for phone users, but they skipped adding special‑case logic for this lecture.

A bug came up during the demo when deleting items. If you deleted the currently selected game, the detail pane kept trying to render the now‑deleted object. Their general‑purpose fix was using the .onChange() modifier watching the games array. Whenever the list of games changed, check whether the currently selected item still exists inside the array. If it no longer exists, reset selection back to nil. I thought this was a smart approach because it works for every deletion pathway, including swipe‑to‑delete and context‑menu delete, not just one specific button action.

There was a small gotcha in the demo code when writing this logic. Inside the onChange closure, they accidentally unwrapped the optional selection into a local let constant and then tried mutating that local copy, instead of assigning back to the original @State property. The lecturer pointed this out as a common mistake when working with optional unwrapping inside SwiftUI closures.
 

Mac target, context menus, and view decomposition

They showed building a Mac application using the “Mac designed for iPad” target option in Xcode. This re‑uses your existing iPad‑oriented SwiftUI code, wrapping it into a proper Mac app with resizable windows and native menu support. Some interactions shift for mouse input: swipe‑to‑delete goes away, but you get drag‑reordering without entering edit mode.

To fill the gap left by missing swipe‑to‑delete on Mac, they demonstrated the .contextMenu() view modifier. Context menus trigger via right‑click on Mac, or long‑press on iOS. Buttons inside context menus should supply both text labels and system image icons. On iOS, context menus visually expect icons next to every menu entry.

Buttons inside context menus can use ButtonRole.destructive. On iOS this colours the button text red to signal destructive actions. The lecturer noted this visual cue does not appear on Mac, even when you set the role. Any destructive action should be wrapped inside withAnimation so list entries animate out when deleted.

A large chunk of this segment was dedicated to refactoring code. They extracted the entire game list logic into a standalone GameList view. When you split views like this, any state you need to modify across parent and child has to be passed as a @Binding. The games collection itself was moved into GameList, and they added sample games inside .onAppear.

This uncovered another bug. .onAppear triggers every time the view comes back on‑screen. On iPhone when navigating back, or when collapsing and expanding the sidebar on iPad, onAppear would fire repeatedly and keep appending duplicate sample games. The simple fix: only populate sample games if the games array is completely empty.

They also walked through creating previews for your decomposed sub‑views. For views that need bindings in previews you can spin‑up temporary @State preview‑only variables, or use .constant(nil). Wrapping your preview inside a NavigationStack is helpful so you can see toolbars and navigation UI elements that your view depends on.

One limitation the lecturer called out: refactoring can create new subtle behavioural side‑effects you would not anticipate. You have to keep testing across device form‑factors after you split your views apart.
 

Building a form‑based game editor and unresolved loose ends

Towards the end of the lecture they started constructing a GameEditor view. This is meant for creating brand‑new games or editing existing ones. The core SwiftUI component here is Form. A Form is a pre‑built combination of scroll view, vertical stack, dividers, and styling. It is what iOS Settings app uses for all its screens. Forms automatically handle keyboard offset adjustments. When a text‑field becomes active and the on‑screen keyboard pops up, the form scrolls content so the text field stays visible above the keyboard.

Inside forms they added TextField for editing the game name. The first argument is the placeholder ghost text you see when the field is empty. The second parameter takes a binding to your string value. They hit a compiler quirk: when you want to create bindings to properties of an @Observable model object inside a child view, you need to mark those properties with @Bindable. Without this attribute you cannot use the dollar‑sign binding syntax on the observable’s stored properties.

Then they added ColorPicker views inside a ForEach loop. They iterated over indices of the peg‑choices array, binding each colour picker directly to an element inside the array. This requires the array property to be declared as var, not let. If it is a constant you cannot bind into individual elements for editing. You can also add sections inside Form to group related inputs.

The lecture ended unfinished. They had the editor view rendering, but were yet to add UI for adding or removing peg entries. They also had not demonstrated how to push or present this GameEditor on screen from the main app. That material was deferred to the next class session. The lecturer noted this work would be relevant for the upcoming course assignment 4, which requires building a settings‑style editing interface. They also teased that future lectures will cover SwiftData for local persistent storage.
 

A point left unresolved in the lecture

The lecturer showed pre‑selecting a game automatically on app startup. This works great for iPad split‑view layouts. But on iPhone it immediately navigates to the detail screen. They mentioned this user experience might feel sub‑optimal for phone users, yet they chose not to implement any conditional behaviour to avoid that outcome. They noted you could use @Environment to read horizontal size classes and branch your logic, but skipped writing that code for this lecture. I was left wondering what practical pattern they would recommend for handling that trade‑off in real‑world projects.