iOS App Migration from Objective-C to Swift
Migration is not rewriting. "Let's rewrite everything in Swift" from scratch is a risky path that breaks accumulated business logic and loses undocumented behavior nuances. Correct migration is gradual, file by file, preserving behavior.
Why Migration is Postponed and Why to Do It Anyway
Postponed due to fear: ObjC/Swift bridging boundary is where nullable/nonnull annotations silently break, NS_SWIFT_NAME renamings confuse, generic types don't pass through header. Fear is understandable.
Done because new Apple APIs come with Swift Concurrency (async/await), SwiftUI, Observation framework — without migration to them, either can't reach them or get ugly wrappers. Plus: Swift compiler catches category of errors (force unwrap on nil, data race via Sendable) before runtime.
Our Migration Approach
Step 1: Audit. Build class dependency graph. Find leaf nodes — classes nothing depends on (utilities, data models, services). Start with them.
Step 2: Annotations in ObjC headers. Before migrating any class, add NS_ASSUME_NONNULL_BEGIN/END to .h files, mark nullable where it's truly nullable. Immediately shows where Swift will have Optional vs not. Skipping this leads to String? everywhere it should be String.
Step 3: Model migration. NSObject subclasses with properties become Swift struct (if value semantics fits) or class (if identity or inheritance needed). @objc attribute needed only where model still used from ObjC code — not everywhere.
Step 4: Services and network layer. Completion-handler-based API rewritten for async/await via withCheckedContinuation or withCheckedThrowingContinuation. Old ObjC callback:
func fetchUser(id: String, completion: @escaping (User?, Error?) -> Void)
Becomes:
func fetchUser(id: String) async throws -> User
ObjC code calling this method continues working via __attribute__((swift_async(...))) or via intermediate ObjC wrapper.
Step 5: ViewControllers. Most complex. Here are IBOutlet, IBAction, delegate patterns, notification observers. Migrate last, when most dependencies already in Swift. Move logic to ViewModel (clean Swift), keep ViewController thin.
Main Traps
@objc inflate. After ViewModel migration, developer adds @objc dynamic to property for KVO support from old ObjC code. Swift compiler stops checking types for those properties as Swift. Solution: move away from KVO to Combine or @Observable (iOS 17+) and remove @objc dynamic.
Bridging header bloat. Large ProjectName-Bridging-Header.h with dozens of #import slows compilation. As migration progresses, remove unneeded imports — compilation noticeably speeds up.
Tests. ObjC unit tests (XCTest) work in Swift target unchanged. But if test tests internal methods of ObjC class via @testable import, when migrating that class access levels may change. Prepare to adapt tests parallel with migration.
Case from practice: mobile banking app, ~80,000 lines ObjC, team of 3 iOS developers. Migrated over 4 months by priority: network layer and models first (reached async/await and removed callback pyramid), then services (auth, analytics, storage), last — screens. Result: crashes from ObjC-related exceptions dropped 70% — just because compiler started catching force-unwrap errors before runtime.
What's Included
- Audit codebase and plan migration by priorities
- nullable/nonnull annotations in ObjC headers
- Step-by-step migration: models → services → ViewModels → UI
- Conversion of completion handlers to
async/await - Unit test adaptation
- Code review and ObjC/Swift boundary check at each step
Timeline
| Codebase Volume | Estimate |
|---|---|
| Up to 10,000 lines ObjC | 2–3 weeks |
| 10,000–50,000 lines | 1–2 months |
| 50,000+ lines | 2–3 months and more |
Timeline depends on ObjC/Swift boundary points count, test coverage, and team readiness for review. Cost calculated individually after codebase audit.