Swift in 2026: What Actually Changed and What Matters for iOS Developers

Swift has changed a lot since the early days, and a post titled “top features” from two years ago is mostly useless now. The language shipped major concurrency work, a new macro system, and real ownership semantics, and the tooling around it changed just as much. Here’s what’s actually worth your time in 2026, with code you can drop into a project today.

Strict concurrency is the default now, not a checkbox

If you turned on Swift 6 language mode when it landed, you already know the pain: hundreds of warnings about sendability, actor isolation, and data races. In 2026 that migration is basically table stakes for new code. The payoff is real. The compiler catches races that used to show up as a crash in TestFlight three weeks later.

The mental model that finally clicked for me: Sendable is a promise about value semantics, not a keyword you sprinkle on until the errors stop. Structs of value types are automatically sendable. Classes are not, unless you make them immutable or isolate them.

// A simple, correct actor for shared state
actor ImageCache {
 private var storage: [URL: Data] = [:]

 func data(for url: URL) -> Data? {
 storage[url]
 }

 func store(_ data: Data, for url: URL) {
 storage[url] = data
 }
}

// Callers await, and the compiler enforces it
let cache = ImageCache()
if let cached = await cache.data(for: imageURL) {
 return cached
}

What trips people up is calling back into the main actor from inside an actor. You cannot just assign to a @MainActor property. You have to hop:

@MainActor
final class ProfileViewModel {
 var name: String = ""
}

actor Loader {
 func load(into viewModel: ProfileViewModel) async {
 let fetched = await fetchName()
 await MainActor.run {
 viewModel.name = fetched
 }
 }
}

That await MainActor.run looks clunky at first. It is also exactly the thing that used to silently corrupt your UI state. I’ll take the clunk.

Macros stopped being a novelty

When macros first shipped, everyone wrote a @Loggable macro and moved on. In 2026 they’re baked into how people write real code, especially around boilerplate that used to require code generation scripts. The two you’ll actually use are attached macros for members and peer macros for adding whole declarations.

@freestanding(expression)
public macro stringify<T>(_ value: T) -> (String, T) =
 #externalMacro(module: "MyMacros", type: "StringifyMacro")

// Usage
let (text, value) = #stringify(2 + 3)
// text == "2 + 3", value == 5

The honest advice: write a macro only when you’ve written the same boilerplate three times. Macros add compile time and they are genuinely hard to debug when they break. For simple cases, a protocol with a default implementation or a generic function is still the better call.

Typed throws finally landed, and they’re narrower than you think

Typed throws (throws(E)) let a function declare exactly what it can throw. This is great for library authors who want callers to exhaustively handle errors without a catch block that swallows everything.

enum ParseError: Error {
 case emptyInput
 case badFormat(Int)
}

func parse(_ input: String) throws(ParseError) -> Int {
 guard !input.isEmpty else { throw .emptyInput }
 guard let value = Int(input) else { throw .badFormat(input.count) }
 return value
}

do {
 let n = try parse("42")
} catch {
 // 'error' is typed as ParseError here, no casting needed
 switch error {
 case .emptyInput: print("nothing to parse")
 case .badFormat(let at): print("bad at index (at)")
 }
}

Note the shorthand throw .emptyInput. When the function’s error type is known, you drop the enum name. Small thing, but it makes error-throwing code read a lot cleaner.

Where typed throws fall down is mixed error sources. If a function calls three things that throw three different error types, you’re back to any Error or wrapping everything in your own enum. Don’t force it into code where it doesn’t fit.

Observation replaced a lot of Combine

The @Observable macro is the biggest quality-of-life change in recent Swift. It removes the need for @Published on every property and it fixes the “everything re-renders when one property changes” problem that plagued ObservableObject.

import Observation

@Observable
final class CartModel {
 var items: [Item] = []
 var couponCode: String?

 var total: Decimal {
 items.reduce(0) { $0 + $1.price }
 }
}

// In SwiftUI, you just read what you need
struct CartBadge: View {
 let cart: CartModel

 var body: some View {
 Text("(cart.items.count)")
 // Only re-renders when items changes, not when couponCode does
 }
}

The catch: it needs a modern deployment target. If you’re still supporting iOS 16 or earlier, you’re stuck with ObservableObject. Check your actual install base before you rewrite anything. Most apps I look at in 2026 can drop iOS 16, but “most” is not “yours.”

Swift on the server is quietly normal

Five years ago, running Swift on Linux for a backend was a novelty. Now it’s a reasonable default for teams that already know Swift, especially if you want to share models and validation logic between an iOS app and an API. Vapor and Hummingbird both work fine on current Swift, and the concurrency story lines up with what you’re already writing on the client.

I do a fair amount of custom web development for clients around Commack and the rest of Long Island, and the interesting shift is how often the mobile and web sides now share a schema. When your Swift model and your TypeScript types both come from one source of truth, you stop shipping bugs where the app and the site disagree about what a field means.

What I’d skip

• Rewriting working code just to use new syntax. If it compiles clean and has tests, leave it. Migration has a cost and the benefit is often zero.
• Macros for one-off cases. Compile time and debuggability are real. Boilerplate you write twice is not a problem worth solving.
• Typed throws everywhere. Use it at API boundaries where callers genuinely need to branch on the error. Inside a module, plain throws is fine.
• Chasing every WWDC feature in the same release cycle. Adopt what solves a problem you have right now.

A sane adoption order

If you’re starting from an older codebase, this is roughly the order I’d move in:

• Turn on strict concurrency as warnings first. Fix the easy ones. Get a feel for the volume.
• Migrate one feature to @Observable and measure. If it doesn’t help, stop.
• Add typed throws at your networking and parsing boundaries only.
• Leave macros alone until you’ve written the same boilerplate three times. Then write one.

None of this is glamorous. It’s the difference between a codebase that gets easier to work in every year and one that gets scarier. That’s the whole game.

FAQ

Do I have to migrate to Swift 6 language mode right now?

No, but you should be running the Swift 6 compiler with warnings on. That gets you the diagnostics without breaking your build. Full migration can happen feature by feature.

Is Combine dead?

Not dead, but for UI state, @Observable covers most of what people used ObservableObject and @Published for. Combine still makes sense for complex stream composition and for code that has to support older OS versions.

Should I write my backend in Swift?

Only if your team already knows Swift well. The tech works. The hiring pool is smaller than Node or Go, so factor that in before you commit.