Swift Best Practices for iOS Apps in 2026

Most “Swift best practices” posts are a list of style rules that stopped being relevant when async/await landed. The language has moved a lot since then, and so has the way we build iOS apps. Here’s what I actually reach for in 2026, and why.

I’ve been writing Swift since the 2.x days and shipping iOS work out of Commack for clients around New York. These are the habits that have survived contact with real projects, not conference slides.

Start with strict concurrency, not as an afterthought

Swift 6’s strict concurrency checking is the biggest shift in years. If you’re still writing code that compiles under Swift 5 language mode, you’re accumulating debt that will be painful to unwind later. Turn on complete checking in a new project from day one.

// In Package.swift or your target build settings:
// SWIFT_STRICT_CONCURRENCY = complete
// SWIFT_VERSION = 6.0

@MainActor
final class ProfileViewModel {
 private(set) var profile: Profile?
 private let service: ProfileService

 init(service: ProfileService) {
 self.service = service
 }

 func load() async throws {
 profile = try await service.fetchProfile()
 }
}

The @MainActor annotation on the whole type is the move most people miss. Instead of sprinkling DispatchQueue.main.async everywhere, you tell the compiler the isolation once and it enforces it. UI state stays on the main actor, and the compiler yells at you when it doesn’t.

For work that genuinely belongs off the main thread, prefer Task.detached sparingly and lean on structured concurrency with task groups. Unstructured tasks leak. If you spawn one, you own cancelling it.

Make illegal states unrepresentable

Enums with associated values are the single best tool Swift gives you for modeling state, and most codebases underuse them. A screen that’s loading, loaded, or failed should be exactly that, not a struct with three booleans that can all be true at once.

enum LoadState<Value> {
 case idle
 case loading
 case loaded(Value)
 case failed(Error)
}

// Then switch exhaustively. No boolean soup.
switch state {
case .idle, .loading:
 showSpinner()
case .loaded(let items):
 show(items)
case .failed(let error):
 showError(error)
}

When you model state this way, whole classes of bugs disappear. You can’t forget to handle the error case because the compiler won’t let you build.

Prefer value types until you have a reason not to

Default to struct and enum. Reach for class when you need reference semantics, identity, or shared mutable state. This isn’t dogma, it’s about reasoning. Value types are copied, so a function that takes one can’t surprise you by mutating your data from three call sites away.

The exception is when you’re modeling something with a real identity, like a database record you’re editing in place, or an object with a lifecycle. Then a class is honest about what it is.

Stop force-unwrapping, but don’t over-guard either

! crashes your app. We all know this. But the opposite failure mode is just as common: nested guard let pyramids that make a simple function unreadable. Swift’s optional chaining and if let shorthand (available since 5.7) clean most of this up.

// Old way
if let user = user {
 if let name = user.name {
 print(name)
 }
}

// 2026 way
if let name = user?.name {
 print(name)
}

// And for defaults:
let displayName = user?.name ?? "Guest"

Use guard for early exits at the top of a function. Use optional chaining in the middle. Reserve ! for things like @IBOutlet connections where a crash genuinely means your storyboard is broken, and even then, @IBOutlet is getting rarer as SwiftUI takes over.

Test the logic, not the framework

Swift Testing replaced XCTest as the default in Xcode 16, and it’s a real improvement. Tests are structs, assertions are macros, and async tests just work without expectation boilerplate.

import Testing

@Test func emptyCartTotalsZero() {
 let cart = Cart()
 #expect(cart.total == 0)
}

@Test func addingItemUpdatesTotal() async throws {
 var cart = Cart()
 try await cart.add(Item(price: 9.99))
 #expect(cart.total == 9.99)
}

Write unit tests for your view models and business logic. Don’t try to unit test SwiftUI views directly, you’ll spend more time fighting the framework than catching bugs. Use previews and UI tests for that layer, and keep the logic in testable types.

Tooling that actually earns its keep

• SwiftFormat for consistent formatting on save. Nobody should argue about brace placement in a code review.
• SwiftLint for the rules formatting can’t catch, like unused code or overly long functions.
• Instruments when something is slow. Profile before you optimize, always.
• Xcode Cloud or a CI runner so tests run on every push, not just when someone remembers.

The temptation is to install every tool in the ecosystem. Don’t. Pick the three that solve a problem you actually have.

Local notes for New York teams

Most of my iOS work comes through Long Island app development projects, and there’s a pattern I see a lot. Small teams here tend to be generalists, one or two devs handling iOS, backend, and everything else. That changes the calculus on best practices. You want a codebase that a single developer can pick up after six months away, which means boring, explicit code beats clever abstractions every time.

It also means you should be aggressive about deleting code. Dead features, unused dependencies, half-finished refactors. On a two-person team, every line you keep is a line someone has to understand later.

The honest summary

Swift best practices in 2026 come down to letting the compiler do more work for you. Strict concurrency catches data races. Exhaustive switches catch missed states. Value types catch accidental shared mutation. None of this is glamorous, and that’s the point. Good Swift isn’t clever, it’s hard to break.

FAQ

Should I migrate my existing app to Swift 6 strict concurrency right now?

Not all at once. Start with new files and new modules, get them clean under strict checking, then migrate the rest module by module. A big-bang migration on a shipping app is how you end up with a two-week feature freeze.

Is SwiftUI ready to replace UIKit entirely?

For most new apps, yes. For apps with heavy custom drawing, complex collection layouts, or deep integration with older code, UIKit still makes sense in places. Mixed projects are fine and normal.

How much of this should I bother with on a solo project?

All of it, honestly. The concurrency rules and state modeling cost you nothing extra to do right the first time and save you enormous time later. The tooling is optional, but formatting and a test target take ten minutes to set up.