Learn SwiftUI | SwiftUI Bootcamp #0
SwiftUI is Apple's modern, declarative UI framework — instead of telling the system how to build your interface step by step, you describe what the UI should look like and let SwiftUI figure out the details. After this bootcamp you'll be able to build real iOS screens from scratch using composable views and modifier chains.
What You'll Learn
- What declarative UI means and why it makes iOS development faster
- How a SwiftUI
Viewstruct and itsbodyproperty work together - How to apply modifier chains to style, size, and position text
Mental Model
Think of SwiftUI like ordering at a coffee shop. You don't walk behind the counter and brew the espresso yourself — you describe what you want ("large oat latte, extra shot") and the barista handles the how. Similarly, you tell SwiftUI "a green, bold, title-sized text" and the framework handles rendering, layout, and redrawing. The description is the UI.
SwiftUI views are value types (structs), which means they're lightweight, copied freely, and recreated whenever the framework needs a fresh snapshot of your UI. The framework compares the old description with the new one and only updates what changed on screen — you never manually call "reload" or "redraw."
Detailed Explanation
SwiftUI replaces UIKit's imperative pattern (create a label, set its text, add it to a view, set constraints) with a purely declarative one. Every screen is a struct that conforms to View and returns a description of its content from a computed body property. That description is made of primitive views — Text, Image, Shape — chained with modifiers.
Modifiers are methods that return a new, slightly modified version of the view they're called on. This is called a modifier chain, and order matters: .frame() applied before .background() gives a different result than .background() applied before .frame(). Read a chain top-to-bottom and ask what kind of change each modifier makes — content, size, color, interaction, or lifecycle.
SwiftUI only uses this simple struct as a starting point. As you progress through the bootcamp you'll add state (@State), navigation, data flow, animations, and networking on top of this same foundation.
Code Structure
The sample lives in a single ContentView.swift file. It defines ContentView (the view itself) and ContentView_Previews (the Xcode canvas preview). The sample intentionally has no state — its only purpose is to demonstrate that a View struct plus a modifier chain is all you need to put something on screen.
Complete Code
ContentView.swift
import SwiftUI
struct ContentView: View {
var body: some View {
Text("Placeholder")
.font(.title) // sets the text style to a large, prominent title
.fontWeight(.black) // applies the heaviest available font weight
.foregroundColor(Color.green) // colors the text green
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView() // renders a live preview of ContentView in the Xcode canvas
}
}Code Walkthrough
import SwiftUI— Brings in the entire SwiftUI framework, including all view types, modifiers, and property wrappers. Every SwiftUI file starts with this line.struct ContentView: View— Declares a value type that conforms to theViewprotocol. Conforming toViewrequires one thing: abodycomputed property.var body: some View— Thesome Viewreturn type is an opaque type. It tells the compiler "this returns some specific View, figure out the type yourself." This avoids writing out the long nested generic types that modifier chains produce.Text("Placeholder")— Creates a simple text view. This is the content — the thing that will appear on screen..font(.title)— Applies the system title font style. Using semantic styles like.titleinstead of a hardcoded point size means the text scales correctly when users change system font size preferences..fontWeight(.black)— Sets the weight..blackis heavier than.bold— useful for hero headings..foregroundColor(Color.green)— Sets the text color. In production you'd use a named color from your asset catalog so it adapts to dark mode.ContentView_Previews— The preview provider allows Xcode to render a live canvas preview without running the simulator. It's compile-time only and never appears in your production app.
Common Mistakes
Mistake: Ignoring the order of modifiers Adding .frame() after .background() vs before it produces completely different visual results because each modifier wraps the previous view in a new layer. When your layout looks wrong, try reading your modifier chain aloud from top to bottom and confirm each step matches your intent.
Mistake: Hard-coding .foregroundColor(Color.green) for production text Hard-coded colors don't adapt to dark mode. Use named colors from your asset catalog (Color("primaryText")) or semantic colors like Color.primary. Save hard-coded colors for learning samples only.
Mistake: Putting logic inside body directly It's tempting to write if, for, and complex expressions right inside body. For small samples this is fine, but as screens grow, extract logic into computed properties or helper functions. A body that's longer than ~30 lines is usually doing too much.
Key Takeaways
- A SwiftUI screen is a
structconforming toViewthat returns a description of its UI frombody - Modifiers are chained calls that each return a modified copy of the view — order matters
- Using semantic font styles and named colors instead of hard-coded values makes your UI adaptive from day one
Last updated: June 27, 2026