> For the complete documentation index, see [llms.txt](https://ios-course.cornellappdev.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ios-course.cornellappdev.com/course-content/week-4-or-swiftui/monday-pre-lecture-skim.md).

# Monday Pre-lecture Skim

Welcome to SwiftUI! This reading covers a few concepts that can feel unfamiliar the first time you see them. Skim through before lecture so the demos and examples click faster.

### Declarative vs. Imperative

* In UIKit (Imperative), you write step-by-step instructions for *how* to build UI. 
* In SwiftUI (Declarative), you describe *what* the UI should look like and the framework handles the rest. 

If you catch yourself asking "when does this code run?" — that's the imperative mindset. In SwiftUI, you just keep your description up to date.

### Structs! Not Classes

SwiftUI views are structs — lightweight value types with no inheritance baggage. Think of them as disposable blueprints, not long-lived objects you mutate over time.

If you're used to thinking of views as long-lived objects that get mutated over time, this is a mental shift!

### Modifiers Create New Views

This is the big one. Each modifier wraps the previous view in a **new view**:

```swift
Text("Hello")
    .padding(20)       // wraps Text in a padded view
    .background(.blue) // wraps THAT in a blue background
```

You're not setting properties like for UILabel — you're nesting wrappers. That's why **order matters**: swapping `.padding` and `.background` changes the result (you will see during demo).

### `some View`

You'll see this in every SwiftUI file:

```swift
var body: some View {
    Text("Hello, world!")
}
```

You'll see `var body: some View` everywhere. It just means "this returns something that conforms to `View`" without you needing to spell out the gnarly concrete type. Don't overthink it.

Why not just write the type? 

* Because after you chain a few modifiers, the actual type becomes something horrific like `ModifiedContent<ModifiedContent<Text, _PaddingLayout>, _BackgroundModifier<Color>>`. The `some` keyword lets Swift figure out the type for you while still guaranteeing it's a `View`. You don't need to fully understand opaque types right now — just know that `some View` is SwiftUI's way of saying "trust me, it's a view."

### Stacks = Layout

SwiftUI replaces Auto Layout constraints with three simple containers:

* &#x20;**HStack** — arranges views horizontally (left to right)
* &#x20;**VStack** — arranges views vertically (top to bottom)
* &#x20;**ZStack** — layers views on top of each other (back to front)

**HStack (horizontal)**, **VStack (vertical)**, **ZStack (layered).** Nest them to build any layout.&#x20;

**Spacer** is a flexible empty view that pushes other views apart. It expands to fill available space:

```swift
HStack {
    Text("Left")
    Spacer()
    Text("Right")
}
```

This pushes "Left" and "Right" to opposite edges — no constraints needed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ios-course.cornellappdev.com/course-content/week-4-or-swiftui/monday-pre-lecture-skim.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.