Swift 6 made strict concurrency the default. Here’s what that actually means for networking, data layers, and UI code in production apps.
Most Swift concurrency tutorials show you a URLSession call wrapped in async/await and call it done. That part is easy. What’s harder — and what caused most of the migration pain when Swift 6 dropped — is understanding what actor isolation actually means and how to structure a real app around it.
I’ve been using AI tools in my iOS workflow for over two years. Here’s what actually saves time, what doesn’t, and how I think about it.
I want to be honest about this upfront: I was sceptical. Not about AI in general — about whether it would actually help with Swift specifically. Swift is opinionated, fast-moving, and the compiler is unforgiving. I wasn’t sure AI tools trained mostly on older codebases would be useful.
App Store submission has gotten stricter. Privacy manifests, required reason APIs, notarisation — here’s what actually trips people up in 2025.
I’ve submitted dozens of apps and updates to the App Store over the years. The process has changed more in the last two years than in the five before that. If you haven’t shipped recently, some of this will catch you off guard.
After 9 years of UIKit and 4 years of production SwiftUI, here’s how I actually decide which framework to reach for on a new project.
I’ve shipped UIKit apps since iOS 7. I’ve been writing production SwiftUI since it was stable enough to trust — which, realistically, was around iOS 15. After all that time, I still get asked the same question from clients and junior devs: which should I use?
