Swift Cheat Sheet

By Bogdan Sandu · Updated August 20, 2026

What Swift Is

Swift is a compiled, statically typed language built by Apple to replace Objective-C, and designed so that the safe way to write something is also the short way. Optionals remove null crashes, value types remove aliasing bugs, and since Swift 6 the compiler catches data races too.

Chris Lattner started it in 2010, Apple announced it at WWDC in 2014, and it went open source in December 2015. Governance now sits with the Swift project, and language changes go through a public proposal process on GitHub rather than being handed down.

It is the default for every Apple platform, but it is not limited to them. Swift compiles on Linux and Windows, powers server frameworks such as Vapor, and runs on microcontrollers through Embedded Swift.

The trade compared with a dynamic language is straightforward. You spend more time being precise about types up front, and in exchange a large class of runtime failures becomes a build error you fix in seconds.

Swift Syntax Basics

Swift reads like a modern curly-brace language. Types come after the name, semicolons are optional and almost never used, and type inference means you rarely write the type at all.

Constants and variables

Use let for anything that does not change, which in practice is most things. The compiler warns when a var is never mutated.

let maximum = 100
var counter = 0
counter += 1

let name: String = "Ada"   // explicit type, usually unnecessary

Functions and argument labels

Swift separates the name the caller uses from the name the body uses. Well chosen labels are why idiomatic Swift reads almost like prose at the call site.

func move(from start: Point, to end: Point) { }
move(from: a, to: b)

func log(_ message: String) { }   // underscore removes the label
log("no label needed")

Control flow

Switch is exhaustive, so leaving out a case is a compile error rather than a silent fallthrough. Since Swift 5.9 both if and switch also work as expressions.

let grade = switch score {
    case 90...: "A"
    case 80..<90: "B"
    default: "C"
}

Optionals, the Idea That Defines Swift

There is no implicit null. A value that might be absent has the type String?, which is a genuinely different type from String, and the compiler will not let you use one where the other is expected.

var middleName: String?          // nil until set

if let middleName {
    print(middleName)            // non optional inside this branch
}

let display = middleName ?? "none"
let length = user?.profile?.bio?.count   // nil if any link is nil

The everyday choice is between if let and guard let. Use guard let when the value is required for the rest of the function, because it exits early and keeps the unwrapped binding in scope below, which flattens nesting considerably.

func greet(_ name: String?) {
    guard let name else { return }
    print("Hello, \(name)")      // name is a plain String here
}

Force unwrapping with ! exists, and it crashes when the value is nil. It is occasionally the honest choice, for a resource you ship inside the app bundle, but every one is a promise about data you may not control.

Value Types and Reference Types

This is the design decision that shapes a Swift codebase most. A struct is a value type: assigning it makes an independent copy. A class is a reference type: assigning it shares one instance.

The guidance from Apple, and from most production codebases, is to start with a struct and move to a class only when you need identity, inheritance, a deinitialiser, or genuinely shared mutable state. Passing large structs around is cheap because Array, String, Dictionary and Set all use copy on write: the underlying buffer is shared until something actually mutates it.

Protocols Instead of Inheritance

Swift is often described as protocol oriented. A protocol declares capability, any type can adopt as many as it likes, and protocol extensions supply default implementations so adoption costs almost nothing.

protocol Greeter {
    var name: String { get }
    func greet() -> String
}

extension Greeter {
    func greet() -> String { "Hello, \(name)" }
}

struct English: Greeter { let name: String }   // greet comes for free

One rule catches everyone once: only methods declared in the protocol body are dynamically dispatched. A method that exists solely in the extension is selected by the static type of the variable, so overriding it in a conforming type will not take effect through a protocol-typed reference.

Since Swift 5.7 the keywords some and any make the cost explicit. Prefer some for parameters and return types, because it stays generic and free. Reach for any only when you need to store different concrete types in one collection.

Concurrency Without Callback Pyramids

Structured concurrency landed in Swift 5.5 and changed how asynchronous code is written. Instead of nesting completion handlers, you write straight-line code with ordinary try and catch.

func loadDashboard() async throws -> Dashboard {
    async let profile = loadProfile()
    async let posts = loadPosts()
    return try await Dashboard(profile: profile, posts: posts)
}

Because the two loads start immediately and the await collects them, this costs the slower of the two rather than the sum. Actors then protect shared mutable state by serialising access, and @MainActor guarantees that anything touching the interface runs on the main thread.

Swift 6 turned strict concurrency checking on by default. Passing a non-Sendable value across an actor boundary is now a compile error, which is uncomfortable during migration and genuinely prevents the intermittent crashes that used to survive code review.

SwiftUI in One Paragraph

A SwiftUI view is a struct describing what the interface should look like for the current state. You never mutate a view. You change state, and the framework works out the smallest redraw.

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack(spacing: 12) {
            Text("Count: \(count)")
                .font(.title)
            Button("Increment") { count += 1 }
        }
        .padding()
    }
}

The @Observable macro introduced in Swift 5.9 replaced most uses of ObservableObject and @Published. It tracks which properties a view actually reads, so changing an unrelated property no longer triggers a redraw.

When Swift Is the Right Choice

• Any Apple platform app: iOS, macOS, watchOS, tvOS and visionOS. There is no serious alternative if you want full platform capability and first day support for new OS features.
• Cross platform mobile with shared logic: Swift for the iOS layer alongside Kotlin on Android is still the highest quality path, and the two languages are close enough that porting logic is quick.
• Server side Swift: worth it when your team already writes Swift and you want one language across client and backend, with real performance and low memory use.
• Command line tools: a single compiled binary with no runtime to install, and Swift Argument Parser makes the interface pleasant.
• Performance sensitive libraries: value semantics and no tracing garbage collector give predictable latency, which matters for audio, graphics and real time work. If that is the draw rather than the Apple platforms, Rust solves the same problem with a stricter compiler and no runtime at all.

It is a weaker fit for quick data exploration, where Python remains far quicker to reach an answer, for teams with no Apple hardware, and for web frontends, where JavaScript and TypeScript remain the sensible defaults.

Learning Path That Actually Works

The order matters. Skipping ahead to SwiftUI before optionals and value semantics are comfortable is the most common way people get stuck.

• Week one: syntax, optionals, collections and control flow. Write small command line programs, not apps.
• Week two: structs, classes, enums with associated values, and error handling. Model something real and notice how enums remove impossible states.
• Week three: protocols, extensions, generics and closures. This is where the language starts feeling expressive rather than strict.
• Week four: SwiftUI and data flow, then async await once you need to fetch something.
• Ongoing: ARC and capture lists, then strict concurrency. Both make far more sense once you have hit the bugs they prevent.

The canonical free resources are The Swift Programming Language, Apple's SwiftUI tutorials, and the API Design Guidelines, which explain why the standard library is named the way it is. Version control matters from day one, so keep a Git reference nearby, and if your app talks to a database the SQL you write against it is unchanged by the client language. Server side Swift deploys as a single binary, so a scratch Docker image is usually all the runtime it needs.

Common Mistakes

• Force unwrapping to silence the compiler: Xcode offers ! as a fix-it, and taking it converts a build error into a crash on a user's device.
• Retain cycles in stored closures: any closure you keep that mentions self needs [weak self]. A closure passed to map does not.
• Reaching for a class out of habit: developers arriving from Java or Objective-C often make everything a class and lose the safety that value semantics provide for free.
• Modelling state with several booleans: three flags describe eight states when only four exist. An enum with associated values makes the other four unrepresentable.
• Ignoring the HTTP status code: URLSession does not treat a 500 as an error, so an unchecked response surfaces later as a confusing decoding failure.
• Creating a DateFormatter inside a loop: it is genuinely expensive to construct. Reuse one, or use the newer formatted API.

Frequently Asked Questions