iOS Architecture Decisions AI Can't Make For You
Why 10+ years of experience still matters in the age of AI-assisted development. A practical guide on when to trust AI and when to rely on your judgment.
In 2025, 41% of all code is AI-generated or AI-assisted. I’m part of that statistic - I use Claude Code daily, I’ve tried Copilot, ChatGPT, and various other tools. AI has genuinely transformed how I work.
But here’s what the hype doesn’t tell you: GitHub Copilot’s suggestions get rejected 70% of the time. And for iOS developers writing Swift, that rejection rate is even higher.
After a decade of shipping iOS apps, I’ve learned exactly where AI saves me hours - and where blindly trusting it would cost me months.
The Swift Problem Nobody Talks About
Let’s start with an uncomfortable truth: AI is significantly worse at Swift than Python or JavaScript.
This isn’t opinion - it’s statistics:
| Language | AI Performance | GitHub Repositories |
|---|---|---|
| Python | Excellent | Millions |
| JavaScript | Excellent | Millions |
| Swift | Good (average) | ~600,000 |
Swift doesn’t even crack the top 20 in the 2025 TIOBE Index. There’s simply less training data. The result? LLMs often suggest outdated patterns - #availability checks for iOS 13, no knowledge of async/await, zero awareness of Swift 6 features.
As Krzysztof Zabłocki noted: “LLMs give you the average of the internet, not the professional best practices you’d write manually.” For iOS engineers, that average is particularly far from production quality.
Where AI Actually Saves Me Time
I’m not anti-AI. Far from it. Here’s where it genuinely accelerates my workflow:
1. Boilerplate Code
When the architecture exists, tests are in place, and requirements are crystal clear - AI handles small changes almost instantly. View models, data models, network layer implementations following established patterns.
2. Documentation
AI cuts documentation time by 50%. Generating docstrings, README updates, inline comments - this is where AI shines.
3. Test Writing
With proper context and clear requirements, AI writes solid unit tests. The catch? You need to understand what to test and why. AI can’t determine your edge cases.
4. Research & Planning
I use AI to analyze codebases, prepare research documents, and explore implementation options. It’s excellent at gathering information - terrible at making decisions.
Where AI Falls Apart
Here’s where 10+ years of experience becomes irreplaceable:
1. Architectural Decisions
Should you go with MVVM, TCA, or clean architecture? Monolith or modular? AI will happily suggest any of them - without understanding:
- Your team’s experience level
- Your product’s 2-year roadmap
- The performance implications for your specific use case
- How this choice affects your App Store review process
I’ve seen AI confidently propose architectures that would require complete rewrites within 6 months. It doesn’t know your business context. It can’t.
2. Scalability Planning
Even for an MVP, architecture should be scalable. You don’t want to rebuild everything in a year. This requires thinking about:
- What features are coming next quarter?
- What’s the product vision?
- What’s the core philosophy of your app?
AI has no visibility into your roadmap. It optimizes for the task at hand, not your future.
3. The Context Problem
AI works brilliantly when context is fully described - examples exist, architecture is established, the task is small and specific.
But for abstract problems? AI struggles. It doesn’t know your app’s history. It doesn’t understand why you made certain tradeoffs. Its context window is limited, and it frequently “forgets” important details mid-conversation.
Sometimes it hallucinates. Sometimes it ignores explicit rules you’ve given it. This isn’t a bug - it’s a fundamental limitation.
4. Swift-Specific Gotchas
The iOS ecosystem moves fast. SwiftUI changes yearly. New frameworks land at every WWDC. AI training data is 2+ years old - it literally doesn’t know what shipped last summer.
Even Apple’s upcoming Swift Assist (Xcode 26) has no web search capability. It can’t access current documentation for new iOS frameworks.
The 70% Problem
A GitClear study analyzing 153 million lines of code found that since AI adoption:
- Code duplication increased 4x
- Short-term code churn is rising
- 75% of developers still manually review every AI snippet before merging
This is the “70% problem” - AI handles routine tasks well but consistently fails at complex architectural decisions. It generates code that looks correct but creates technical debt.
My Framework: When to Trust AI vs. Your Judgment
After thousands of hours working with AI tools, here’s my decision framework:
Use AI when:
- Requirements are clearly defined
- Examples and patterns exist in your codebase
- Tests can verify correctness
- The task is isolated and small
- You can review every line it generates
Use your judgment when:
- Defining product vision and roadmap
- Making architectural decisions
- Evaluating scalability tradeoffs
- Considering team dynamics and skills
- Planning for features that don’t exist yet
The key insight: AI is a tool that comes AFTER the work of a business analyst and architect. It executes well-defined tasks. It doesn’t define them.
Conclusion: AI as Amplifier, Not Replacement
I’m bullish on AI for development. It genuinely makes me faster - when used correctly.
But I’d never rely on AI for the general approach of a serious project. The vision, the roadmap, the core philosophy, the architectural foundation - these require human judgment. They require understanding context that no model can access.
The developers who thrive in the AI era won’t be those who blindly accept suggestions. They’ll be the ones who know exactly when to use AI as an accelerator - and when to close the chat and think.
What’s your experience using AI for iOS development? I’d love to hear where it’s helped and where it’s failed you. Connect with me on LinkedIn or X.
Sources: