Swift App Development Best Practices for 2026

Most “best practices” posts for Swift are written by people who haven’t shipped an app in years. I’ve been building iOS apps for over a decade, and the language and tooling have changed enough in the last two releases that a lot of old advice is now actively wrong. Here’s what I actually do in 2026.

Stop writing completion handlers. Use async/await everywhere.

If you’re still threading callbacks through your networking layer, you’re writing code that’s harder to read and easier to get wrong. Structured concurrency has been stable for years now. There’s no good reason to write a new URLSession call with a completion handler in 2026.

struct UserService {
 let session: URLSession = .shared

 func fetchUser(id: Int) async throws -> User {
 let url = URL(string: "https://api.example.com/users/(id)")!
 let (data, response) = try await session.data(from: url)

 guard let http = response as? HTTPURLResponse,
 (200..<300).contains(http.statusCode) else {
 throw ServiceError.badResponse
 }
 return try JSONDecoder().decode(User.self, from: data)
 }
}

Notice there's no manual error plumbing and no callback pyramid. The caller just try awaits it. If you need to kick off several at once, use a task group rather than chaining them.

Actors are not a silver bullet

Swift's actor model solves data races on shared mutable state, but people overuse it. An actor serializes access, which means every call is a potential suspension point. For a simple value type with no shared mutation, you don't need an actor. Reach for one when you actually have state that multiple tasks touch at the same time, like a cache or a connection pool.

Also: mark your view models and services as @MainActor when they drive UI. It saves you from sprinkling DispatchQueue.main.async around and it's checked at compile time.

SwiftUI architecture: keep the view dumb

SwiftUI is mature now, but the complaints haven't changed. The reason people say it "doesn't scale" is usually that they put business logic inside the view. Views should render state. That's it.

I keep a plain observable model that owns the state and the async work, and the view observes it. No giant view bodies doing network calls.

@MainActor
@Observable
final class ProfileViewModel {
 private(set) var user: User?
 private(set) var errorMessage: String?

 private let service: UserService

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

 func load(id: Int) async {
 do {
 user = try await service.fetchUser(id: id)
 } catch {
 errorMessage = "Couldn't load that profile."
 }
 }
}

The @Observable macro replaced a lot of the old ObservableObject boilerplate. If you're on an older codebase still using @Published everywhere, migrating is worth the afternoon it takes.

Testing: test behavior, not implementation

Swift Testing is the default now, and it's a real improvement over XCTest for unit tests. It's more concise and the async support is cleaner. A few things I stick to:

• Inject dependencies so you can swap in a fake. Don't hit the real network in tests.
• Test what the code does, not how it does it. Tests that assert on private internals break every time you refactor.
• Keep UI tests few and focused on real user flows. They're slow and flaky if you lean on them for logic.

import Testing

@Test func profileLoadsUser() async throws {
 let fake = FakeUserService(user: User(id: 1, name: "Test"))
 let vm = ProfileViewModel(service: fake)

 await vm.load(id: 1)

 #expect(vm.user?.name == "Test")
 #expect(vm.errorMessage == nil)
}

Performance and app size still matter

Nobody installs a 200 MB app they don't need. A few things that pay off:

• Use Swift Package Manager for dependencies so you can prune unused code. Fewer dependencies is always better.
• Turn on dead code stripping and check your build size after every release, not once a year.
• Profile with Instruments before optimizing. Guessing where the slowness is wastes days.
• Lazy-load images and lists. A LazyVStack instead of a VStack in a scroll view is a one-line change with a big payoff.

Ship small, ship often

The teams that struggle are the ones that batch six months of work into one release. The ones that do well push small changes, use TestFlight for real feedback, and fix things in days instead of quarters. This isn't specific to Swift, but it's the single biggest predictor of whether an app stays healthy.

If you're building an iOS product and want the codebase to still make sense two years from now, the choices above are what get you there. If you'd rather hand it off, this is the kind of work I do through Long Island app development, and it's the same set of standards whether you're in Commack or anywhere else.

FAQ

Should I still learn UIKit in 2026?

Yes, but less than before. SwiftUI covers most new apps, but you'll hit UIKit when you need a specific control, deep customization, or you're maintaining an existing app. Know enough to bridge the two.

Is async/await always faster than callbacks?

Not necessarily faster at runtime. It's clearer and less error-prone, which is why it wins. The performance difference is negligible for normal app work.

How many dependencies should a typical iOS app have?

As few as you can get away with. Every package is something you have to keep updated and audit. If you can write it in a day, write it.