Intro to Xcode and SwiftUI— Annotated Lecture Notes & Key Takeaways

This is the first lecture of  iOS Development with SwiftUI for Spring 2025, taught by Paul Hegarty, who’s been teaching this course since the earliest days of the iPhone. The session runs through a quick course overview, a guided spiral tour of the Xcode development environment, and the very first fundamentals of how SwiftUI works. If you missed class, these notes walk you through the key points, plus call out the parts that felt trickiest to follow on first listen.

How the Course Is Structured (and What You Need to Keep Up)

Hegarty opens with a clear warning: this is not a beginner coding class. The number one prerequisite is comfort writing large amounts of code. If you’re coming straight out of an intro class like CS106A, the workload will feel overwhelming. It helps significantly to have experience with multiple programming languages, since Swift will be new for nearly everyone in the room.

The course uses what Hegarty calls a narrative approach. Instead of building dozens of tiny separate example apps, we’ll spend the first six or seven weeks building one single, large app together, like writing a novel. Characters, plot, and settings stay consistent as the app grows more complex. This gives you a feel for what it’s actually like to build a big, real-world application, rather than just knowing isolated bits of syntax.

He contrasts this with the vignette approach—looking up how to use a single component like a scroll view on Google or ChatGPT when you need it. Both methods matter. The narrative gives you the foundation, and vignette learning is how you’ll pick up new features on your own for the final project.

Grades are based on five programming assignments that build directly on top of each other. Fall behind on the first one, and you’ll cascade into trouble on all the rest. The final project takes up the last three weeks of the quarter. You can work individually or in teams of two, and you pick your own app idea. The whole point of the final project is to prove you can teach yourself new SwiftUI concepts independently.

One important note that might catch people off guard: this is not object-oriented programming. Even though some syntax might look familiar, Swift and SwiftUI use functional and protocol-oriented programming. Almost no one in the room has experience with this, so expect a steep initial learning curve.

The Xcode Interface, Spiral Tour

Hegarty walks through the Xcode interface starting from the top left corner and spiraling inward, pointing out only the parts we’ll actually use at first. I found it a little overwhelming how many panels and features there are, but he emphasizes repeatedly that we won’t touch most of them for weeks, and we’ll learn things as we need them.

On the left side is the Navigator. It lets you browse project files, search and replace across the entire codebase, view breakpoints, and see logs from previous builds. Most of the time you’ll probably keep it closed to save screen space, using the jump bar at the top of the editor to navigate between files instead.

At the top middle is the play button, which runs your app on whatever destination you select. You can choose from various iPhone, iPad, and Mac simulators, or plug in a physical device. You can even run wirelessly if your Mac and iPhone are on the same Wi‑Fi network.

On the right side is the Inspector. It shows details about whatever you have selected in the editor, and lets you modify things like font and color without typing code. It’s useful for designers and localizers, but we won’t use it much in this class since we’re learning to write UI in code.
Along the bottom is the console and debugger area. We’ll use print statements to the console constantly for early debugging, especially since SwiftUI’s reactive nature can make it hard to tell what’s happening just by looking at the interface.

The real star of the tour is the preview canvas on the right side of the editor. It shows your UI updating live as you type, with no need to hit the run button every time you make a change. You can toggle to select mode, where clicking an element on the preview jumps you straight to the corresponding code. Hegarty estimates about 95% of UI features work correctly in preview, 99% work in the simulator, and 100% work on a real device. Complex animations are the main thing that doesn’t always render perfectly in preview.

He also shows the library, accessed via the plus button. It’s stocked with all the built‑in views, hundreds of view modifiers, reusable code snippets, colors, and Apple’s SF Symbols icon set. Mastering SwiftUI, he notes, is basically just learning all those view modifiers over time.

SwiftUI Fundamentals: Views and the LEGO Analogy

This is the real core of the lecture, and Hegarty uses a LEGO analogy to make it all click. It sounds silly at first, but it works surprisingly well for wrapping your head around how views compose.

First, the basics: a View is not a class. It’s a protocol. You make your own structs conform to the View protocol. There’s no inheritance involved at all, which is the biggest break from object‑oriented UI frameworks. When you conform to View, you get all the hundreds of built‑in view modifiers for free. In exchange, you have to implement exactly one required thing: a computed property called body that returns some View.

Now the LEGO breakdown:

• Basic bricks are simple built‑in views like Text, Image, and Circle. These are the fundamental building blocks.

 

• Custom builds are your own views, like the default ContentView. They’re assembled from other views, but they themselves are fully valid Views—just like a LEGO helicopter is made of smaller bricks but is still a LEGO piece you can use elsewhere.

 

• Bags of bricks are groups of multiple views, technically called TupleView. You will almost never type that name yourself.

 

• Instruction manuals are layout views like VStack, HStack, and ZStack. Their only purpose is to arrange other views according to rules.

VStack is the first layout view we look at. It takes three parameters: alignment (default is centered), spacing (defaults to Apple’s recommended platform‑standard gap, so you usually leave it alone), and content. The content parameter is itself a function that returns a View.

This is where @ViewBuilder comes in. Normally a function can only return one value, but the @ViewBuilder attribute lets you list multiple views inside a closure, and it automatically wraps them all up into that TupleView bag behind the scenes. That’s why you can just list Text, Image, and Circle one after another inside a VStack without manually combining them.

One point that was hard to follow at first is some View. Since the body property can return different types of views depending on if statements and other logic, writing out the actual concrete type would be extremely long and messy. some View is compiler magic that means “this returns one specific type that conforms to View, and I’ll let the compiler figure out exactly what it is.” You never have to write out the full TupleView type yourself.

There’s also the trailing closure syntax rule to wrap your head around. When the last argument to a function is itself a function, you can move it outside the parentheses and even omit the argument label entirely. That’s why you see VStack { ... } instead of VStack(content: { ... }). It’s purely syntactic sugar to make the code read more cleanly, but it can look like total magic if no one points out the rule behind it.

One small but thoughtful detail: layout alignment uses .leading and .trailing instead of left and right. This automatically adjusts for right‑to‑left languages like Arabic and Hebrew, so your interface feels natural for everyone. It’s a small example of how Apple builds internationalization into the framework by default.

Hegarty wraps up by saying the next lecture will cover more layout options and the basics of view modifiers, then we’ll dive straight into building the Codebreaker game app.