AI-Assisted iOS Development: My Actual Workflow with Claude and Cursor
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.
I was wrong. But not in the way the hype would lead you to expect.
What I Use and Why
My current stack is Cursor as my primary editor (it’s VS Code with AI deeply integrated) and Claude for anything that needs longer context or architectural thinking. GitHub Copilot occasionally for quick autocomplete when I’m in Xcode directly.
I still write a lot of code by hand, in Xcode, with a Swift compiler telling me immediately when I’m wrong. The AI tools augment that — they don’t replace it.
Where AI Actually Saves Me Time
Boilerplate that’s genuinely tedious: SwiftUI Codable conformances for complex nested types, URLSession networking layers with proper error handling, CoreData stack setup — these are things I’ve written hundreds of times. I know exactly what they should look like. Having AI generate a solid starting point and me reviewing and adjusting it is faster than typing it myself.
Cross-referencing APIs I use infrequently: MapKit and Core Location have a lot of surface area. When I’m doing something I haven’t done in a year — setting up a custom map overlay, or working with CLMonitor — Claude can surface the right API and a working example faster than documentation browsing.
Writing tests: This is underrated. Given a function, Claude generates meaningful unit tests quickly. I still review every test, but the scaffolding is done. My test coverage is higher than it would be if I had to write every test from scratch.
Explaining compiler errors in context: Swift 6 strict concurrency errors can be cryptic. Pasting the error with surrounding code into Claude usually gets me a clear explanation and a concrete fix within one turn.
Where I Don’t Trust It
Architecture decisions: AI will give you an answer, confidently. It won’t always be the right answer for your specific app. I use AI to explore options, not to decide between them.
Anything touching App Store review or Apple-specific policies: The training data is outdated. Privacy manifest requirements, StoreKit 2 details, the current App Review guidelines — always verify against Apple’s actual documentation.
Complex concurrency: AI-generated async/await code often has subtle actor isolation issues that compile but behave incorrectly at runtime. I’m much more careful here — I treat AI suggestions as a starting point that needs thorough review.
SwiftUI layout edge cases: The generated code often works in simple cases but breaks in the exact edge case you care about. Faster to just know SwiftUI’s layout system yourself.
How I Actually Use Cursor
Cursor’s inline edit (Cmd+K) is where most of the value is for me. Select a function, describe what I want to change, review the diff. It’s fast and the diff view makes it easy to catch mistakes.
For bigger tasks, I use Cursor’s Composer. I’ll describe a feature — “add a location permission request flow that handles the denied state and links to Settings” — and iterate from there. The first output is usually 70-80% right. The remaining 20% is where my Swift knowledge matters.
The Honest Takeaway
AI tools have made me faster. Not by a factor of ten — that’s hype. Maybe 30-40% faster on the kind of feature work I do most. The productivity gain is real, but it’s because I know Swift well enough to review AI output critically and fix it quickly when it’s wrong.
Junior devs who use these tools without a solid foundation end up with code they can’t debug when it breaks. The AI writes confidently whether it’s right or wrong. The skill is knowing which is which.
I’m a faster iOS developer because of these tools. I’m still an iOS developer.
