Swift
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Optionals
-
Section 4: Object-Oriented and Value Types
-
Section 5: Memory Management
-
Section 6: Generics and Error Handling
-
Section 7: Concurrency
-
Section 8: Working with Collections
-
Section 9: Codable and Data Handling
-
Section 10: Protocol-Oriented Programming
-
Section 11: Testing and Tooling
-
Section 12: Practical Projects
-
Section 13: Interview Practice
-
Section 14: More Practice Exercises
-
Section 15: More Standard Library
-
Section 16: Advanced Concurrency
-
Section 17: Foundation Framework Deep Dive
-
Section 18: URLSession and Networking Deep Dive
-
Section 19: Combine Framework
-
Section 20: SwiftUI Fundamentals for Swift Developers
-
Section 21: Server-Side Swift with Vapor
-
Section 22: Swift Package Manager Deep Dive
-
Section 23: Swift Concurrency Deep Dive
-
Section 24: More Language Features
-
Section 25: Error Handling Deep Dive
-
Section 26: Testing Deep Dive
-
Section 27: Data Structures and Algorithms in Swift
-
Section 28: More Practice Exercises
-
Section 29: More Interview Practice
-
Section 30: Swift Macros (Swift 5.9+)
-
Section 31: Property Wrappers Ecosystem
-
Section 32: Swift Interop Deep Dive
-
Section 33: iOS App Architecture Patterns
-
Section 34: Performance and Debugging
-
Section 35: App Distribution and CI/CD
-
Section 36: More Practical Projects
-
Section 37: SwiftData and Persistence
-
Section 38: More Design Patterns
-
Section 39: More Review and Practice
-
Section 40: More Foundation Deep Dive
-
Section 41: Advanced Collections in Swift
-
Section 42: Advanced Generics Practice
-
Section 43: UIKit for Legacy and Hybrid Apps
-
Section 44: watchOS and visionOS Development Basics
-
Section 45: More Networking Patterns
-
Section 46: More Testing Practice
-
Section 47: Accessibility in Swift Apps
-
Section 48: Localization
-
Section 49: More Practical Projects Round 2
-
Section 50: Swift Charts Framework
-
Section 51: More Interview and Algorithm Practice
-
Section 52: Final Practice and Mastery
-
Section 53: Swift Compiler and Build System
-
Section 54: More Concurrency Practice
-
Section 55: App Store Guidelines and Review
-
Section 56: More Design and Architecture
2: Anatomy of a Swift Program
When I see developers moving to Swift from Java or C#, the first thing they usually do is wrap their entire program in a class or a main() function. They've been trained to believe that the compiler will throw a tantrum if there isn't a formal "entry point" wrapping every single line of code. In those languages, that's a rule. In Swift, it's often an unnecessary hurdle.
The "Everything Needs a Wrapper" Trap
You might think you need to structure a simple script like this just to get it to run:
import Foundation
class Program {
func run() {
let greeting = "Hello, Swift!"
print(greeting)
}
}
let myProg = Program()
myProg.run()
Now, this isn't "wrong" in the sense that it won't compile, but it's overkill. You're building a house around a single chair. In Swift, specifically in top-level code (like in a main.swift file or a Playground), you can just... write the code. The compiler is smart enough to treat the top level of your file as the executable entry point.
The Actual Hierarchy of a Swift File
If you look at a professional Swift file, you'll notice a specific rhythm to the anatomy. It's less about following a rigid rulebook and more about a logical flow from "global" to "specific."
First, you have your Imports. I always put these at the very top. You're telling Swift, "Hey, I need tools from this other toolbox." For example, if you want to use Date or UUID, you need import Foundation. If you're building a UI, you'll see import SwiftUI.
Next, you'll often see Global Constants or Configuration. These are values that the entire file needs to know about, defined using let. I personally prefer keeping these near the top so I don't have to hunt through 200 lines of code to change a timeout value or an API key.
Then come the Type Definitions. This is where your structs, enums, and classes live. This is the "blueprint" section of your anatomy. You aren't actually *doing* anything yet; you're just describing what the data looks like.
Finally, you have the Execution Logic. This could be a function call, a loop, or a series of statements that actually trigger the behavior of your program. Here is a concrete example of how this actually looks in a real-world scenario—a simple fuel efficiency tracker:
import Foundation // 1. The Toolbox
let milesPerGallonThreshold = 25.0 // 2. Global Configuration
struct Vehicle { // 3. The Blueprint
let model: String
let mpg: Double
}
func evaluateEfficiency(for vehicle: Vehicle) { // 3. The Blueprint (Logic)
if vehicle.mpg >= milesPerGallonThreshold {
print("\(vehicle.model) is efficient!")
} else {
print("\(vehicle.model) is a gas guzzler.")
}
}
// 4. The Execution
let myTruck = Vehicle(model: "Ford F-150", mpg: 18.5)
evaluateEfficiency(for: myTruck)
Notice that the evaluateEfficiency function is defined before it's called, but in Swift, this isn't actually a requirement. You could move that function call to the top of the file, and it would still work perfectly. Swift scans the file for declarations before it executes the top-level code. This gives you the freedom to organize your file based on what makes the most sense for a human to read, not what the compiler demands.
📋 Practical Task
Refactoring the Movie Library Skeleton
You've been handed a messy piece of code for a Movie Library app. The previous developer wrapped everything in an unnecessary LibraryManager class and put the imports in the middle of the file. This is making the code harder to read and maintain.
Your Task: Refactor the following code to follow the proper Swift anatomy:
- Move the
importto the very top. - Remove the
LibraryManagerclass wrapper entirely. - Move the
minRatingconstant to the top-level global scope. - Ensure the
Moviestruct and thecheckRatingfunction are defined clearly before the execution logic.
struct Movie {
let title: String
let rating: Double
}
class LibraryManager {
let minRating = 7.0
func checkRating(movie: Movie) {
if movie.rating >= minRating {
print("\(movie.title) is worth watching.")
} else {
print("\(movie.title) skip it.")
}
}
}
import Foundation
let manager = LibraryManager()
let movie1 = Movie(title: "Inception", rating: 8.8)
manager.checkRating(movie: movie1)
There are no comments for now.