Imagine an Objective-C codebase that needs to be translated to Swift without stopping new feature development. We use step-by-step migration: file by file, preserving behavior and not breaking business logic. Full rewrite from scratch is a risky path that loses nuances not documented in the code. Our 5-year experience migrating iOS apps guarantees a smooth transition without downtime. Over 30+ projects, we've developed a process that minimizes regressions and maximizes team productivity.
Why is migration often postponed?
Postponed due to fear: the ObjC/Swift bridging boundary is where nullable/nonnull annotations quietly break, NS_SWIFT_NAME renames confuse, and generic types don't propagate through headers. The fear is understandable: errors at the boundary of two languages appear not immediately but at runtime. However, postponing migration means losing access to new Apple APIs—Swift Concurrency (async/await), SwiftUI, Observation framework. Without migration, either you can't use them or you end up with ugly wrappers. Plus, the Swift compiler catches a category of errors (force unwrap on nil, data race through Sendable) before runtime—this reduces crash rates by an average of 70%.
What does migration bring besides access to new APIs?
The Swift compiler detects up to 70% of potential crashes already at build time—three times more effectively than Objective-C. Additionally, migration simplifies maintenance: code becomes more readable, lines of code decrease by an average of 30%, and using value semantics (struct) reduces bugs related to shared mutable state. In one banking app project (~80,000 lines of ObjC), we reduced crashes by 70% after migration—simply because the compiler started catching force-unwrap errors before runtime. The development team's velocity increased by 25% as a result.
When is it better to migrate and when to wait?
Migration should start if you plan to use new Apple APIs (SwiftUI, async/await), if crash rates are rising, or if the team spends significant time maintaining ObjC code. It can be postponed if the app is stable and doesn't require new features, but this becomes harder each year. Average savings on maintenance after migration amount to $10,000–20,000 per year due to reduced debugging and bug fixing time.
How we approach migration
Step 1: Audit. We build a dependency graph between classes. We look for leaf nodes—classes that depend on nothing (utilities, data models, services). We start with those.
Step 2: Annotations in ObjC headers. Before migrating any class, we set NS_ASSUME_NONNULL_BEGIN/END in .h files, marking nullable where it is actually nullable. This immediately shows where Swift will have Optionals and where not. Skipping this step leads to String? everywhere there should be String.
Step 3: Migrating models. NSObject subclasses with properties become Swift structs (if value semantics fit) or classes (if identity or inheritance is needed). The @objc attribute is only needed where the model is still used from ObjC code—not everywhere.
Step 4: Services and network layer. Completion-handler-based APIs are rewritten to 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 to work via __attribute__((swift_async(...))) or through an intermediate ObjC wrapper.
Step 5: ViewControllers. The most complex. Here we have IBOutlet, IBAction, delegate patterns, notification observers. We migrate them last, when most dependencies are already in Swift. We move logic into ViewModels (pure Swift), leaving ViewControllers thin.
What pitfalls are encountered?
@objc inflation. After migrating a ViewModel, a developer adds @objc dynamic to a property to support KVO from legacy ObjC code. The Swift compiler then stops type-checking these properties as Swift. Solution: move away from KVO to Combine or @Observable (iOS 17+) and remove @objc dynamic.
Bridging header bloat. A large ProjectName-Bridging-Header.h with dozens of #import slows compilation. As migration progresses, we remove unneeded imports—compilation noticeably speeds up (up to 40% faster).
Tests. ObjC unit tests (XCTest) work in a Swift target unchanged. But if a test tests internal methods of an ObjC class via @testable import, access levels may change when that class migrates. We prepare to adapt tests in parallel with migration.
A mobile banking app, ~80,000 lines of ObjC, team of 3 iOS developers. Migrated in 4 months by priority: first network layer and models (moved to async/await and eliminated callback pyramids), then services (auth, analytics, storage), finally screens. Result: crashes due to ObjC-related exceptions decreased by 70%—simply because the compiler started catching force-unwrap errors earlier at runtime. Source: experience from a banking app migration
Comparison of migration approaches
| Criterion |
Full rewrite |
Step-by-step migration |
| Time |
6–12 months |
2–4 months (depends on size) |
| Risks |
High (loss of business logic) |
Low (behavior preserved) |
| Parallel new features |
No |
Yes |
| Testing requirements |
Full re-testing |
Incremental testing |
What is included in the work
- Codebase audit and creation of a prioritized migration plan
- Adding nullable/nonnull annotations in ObjC headers
- Step-by-step migration: models → services → ViewModels → UI
- Converting completion handlers to async/await
- Adapting unit tests
- Code review and verification of the ObjC/Swift boundary at each stage
- 30-day post-migration support and documentation handover
Timelines
| Codebase size |
Estimated timelines |
Cost range (USD) |
| Up to 10,000 lines ObjC |
2–3 weeks |
$3,000–$5,000 |
| 10,000–50,000 lines |
1–2 months |
$5,000–$15,000 |
| 50,000+ lines |
2–3 months or more |
$15,000–$30,000+ |
Timelines depend on the number of ObjC/Swift boundary points, existence of tests, and team readiness to participate in reviews. Cost is calculated individually after a codebase audit. Request a free audit of your codebase—we will assess the workload and propose a migration plan. Contact us to discuss details.
Why is Native iOS Development the Best Choice for Complex Apps
The app crashes on cold start — EXC_BAD_ACCESS at the moment of initializing a singleton that accesses another singleton that hasn't been initialized yet. Or: a ViewController leaks memory because a closure captures self without [weak self], and that ViewController hangs in memory two transitions after the user left it. These are not hypothetical scenarios — they are the two most common classes of problems on iOS projects that come to us after another team.
We have been doing iOS development for over 5 years, delivered 40+ projects of varying complexity — from startups to enterprise solutions with millions of users. Each project undergoes 3 stages of Code Review, a custom set of UI tests (150+ test cases on average), and a mandatory run through Xcode Instruments before release.
Native iOS development with Swift means direct access to the platform. No middleware, no performance compromises, full control over what happens on every frame.
What Makes Native iOS Development on Swift the Choice for Enterprise Apps?
Native code guarantees compatibility with new Apple APIs on the day they are released, not after months of adaptation in cross-platform frameworks. For apps with latency-sensitive logic (financial terminals, medical monitors, AR navigation), this is critical. Swift with ARC and strict typing allows maintaining a crash-free rate of 99.9% with proper architecture.
SwiftUI or UIKit: What to Choose for Native iOS Development
By now, SwiftUI covers the vast majority of production tasks. But UIKit is not deprecated and will not disappear — Apple does not deprecate it but continues to add APIs. The real picture on large projects: a hybrid approach. SwiftUI for most screens, UIKit where SwiftUI hits limitations.
Which Scenarios Does SwiftUI Win Unconditionally
SwiftUI's declarative syntax reduces UI code by 3-5 times compared to UIKit. A settings screen with List, Toggle, Picker — that's 40 lines of SwiftUI versus 200 lines of UIKit with UITableViewDataSource delegates. Time savings on UI development reach 60%. Apple recommends starting new projects on SwiftUI (Human Interface Guidelines).
@State, @Binding, @ObservableObject (and with iOS 17, the @Observable macro) create a reactive link between data and UI without manual reloadData(). Changing a @State variable automatically redraws the affected part of the hierarchy. This works correctly if you understand how SwiftUI computes the diff — via Equatable and id in ForEach.
AsyncImage, NavigationStack with type-safe routing via NavigationPath, searchable, refreshable — these are ready-made patterns that UIKit requires implementing manually.
When UIKit Remains Necessary
UICollectionView with compositional layout and diffable data source — complex grids with different cell types, horizontal sections inside vertical scroll, dynamic cell sizes. SwiftUI LazyVGrid / LazyHGrid do not provide such control.
Custom transitions between screens. UIViewControllerAnimatedTransitioning and UIViewControllerInteractiveTransitioning — interactive pop gesture with partial progress, custom hero transition with precise frame control. SwiftUI matchedGeometryEffect covers some cases, but not all.
UITextView with TextKit 2. Rich text editor, custom attributes, custom rendering — TextKit 2 (available since iOS 16) switched to async layout, solving performance issues on long documents. SwiftUI TextEditor is a wrapper around UITextView without direct access to TextKit.
UIScrollView with custom behavior. scrollViewDidScroll, parallax effects, sticky headers with custom logic, pull-to-refresh with custom indicator. SwiftUI ScrollView with scrollPosition and onScrollGeometryChange (iOS 17) covers some cases, but not all.
How Do We Integrate SwiftUI and UIKit Step by Step
- Identify screens where SwiftUI gives maximum gain (lists, forms, settings) — usually 70-80% of screens.
- For performance-critical areas (complex collections, custom animations) leave UIKit.
- Use
UIHostingController to embed SwiftUI views into UIKit navigation stack.
- For backward compatibility, wrap UIKit components via
UIViewRepresentable.
- Coordinator pattern (UIKit) manages navigation at the flow level, screens are implemented in SwiftUI.
One pattern we use on projects: UIKit coordinator manages navigation, while the screens themselves are in SwiftUI. The coordinator creates a UIHostingController, passes ViewModel via initializer or @EnvironmentObject, and manages transitions. This gives clean separation: SwiftUI handles UI, Coordinator handles navigation.
How async/await and Combine Work Together
Before Swift 5.5, asynchronous code on iOS was built on Combine or callback chains. With the advent of async/await and Actor, concurrency has become part of the language. On new projects we use async/await as the primary tool for network calls and business logic, and Combine for reactive UI state binding.
// Correct — @MainActor guarantees UI updates on main thread
@MainActor
class UserViewModel: ObservableObject {
@Published var user: User?
@Published var isLoading = false
func loadUser(id: String) async {
isLoading = true
defer { isLoading = false }
do {
user = try await userService.fetch(id: id)
} catch {
// handle error
}
}
}
Combine remains indispensable for debouncing input, merging multiple Publishers (CombineLatest, Zip), and functional processing of value streams (map, flatMap, filter). In practice, 80% of projects use both approaches, choosing the tool for the task.
iOS App Architecture
MVVM — the basic pattern. ViewModel contains logic and @Published state, SwiftUI View subscribes via @ObservedObject or @StateObject. One rule: View knows nothing about URLSession, CoreData, UserDefaults.
Clean Architecture adds Repository and UseCase layers. UserRepository abstracts the data source (network vs cache). FetchUserUseCase contains business logic. UserViewModel calls UseCase and manages UI state.
TCA (The Composable Architecture) — a stricter pattern from Point-Free. State, Action, Reducer, Effect — everything explicit, testable, composable via Scope. Works well in large teams (5+ iOS developers) where predictability is important.
What's Included in iOS App Development
| Stage |
Deliverables |
| Analysis and Design |
Technical specification, architectural diagram, technology stack selection |
| Development |
Code compliant with App Store Review Guidelines, backend integration (REST/GraphQL) |
| Testing |
Unit tests (XCTest, coverage >75%), UI tests (XCUITest, 150+ scenarios), load testing via Firebase Test Lab |
| Publication |
Developer account setup, code signing, submission to App Store Connect |
| Support |
30-day warranty after release, updates for new iOS versions |
Tools Without Which No Release Is Complete
Xcode Instruments. Time Profiler shows where CPU spends time. Allocations — memory leaks and excessive allocations. Leaks — objects that are not freed. Before every release — a mandatory run.
Firebase Crashlytics. Crash-free rate, grouping by stack trace, breadcrumbs of events leading to crash. Set up in 30 minutes, provides visibility across the entire device fleet. On our projects, average crash-free rate is 99.8%.
Fastlane match. Manage certificates and provisioning profiles via an encrypted git repository. Eliminates the 'it builds locally but not on CI' issue once and for all. Saves up to 4 hours per build when signing manually.
XCTest + XCUITest. Unit tests for ViewModel and UseCase, UI tests for critical flows (onboarding, payment, authorization). On average, code coverage is 75%.
Typical iOS Project Mistakes and Their Solutions
| Problem |
Solution |
Memory leak due to self capture in closure |
Use [weak self] in all handlers where self does not need to outlive the closure |
| Provisioning Profile conflicts |
Set up Fastlane match and store certificates in a separate repository |
| Slow app start due to synchronous singleton initialization |
Move initialization to first call or use lazy var |
| App Store rejection due to Section 4.2 (minimal functionality) |
Conduct a preliminary audit using the App Store Review Guidelines checklist |
Process and Timelines
| Complexity |
Estimated Timeline |
| MVP (5–8 screens, basic API) |
6–10 weeks |
| Medium app (15–25 screens) |
3–5 months |
| Complex (payments, AR, CoreML, custom UI) |
5–9 months |
Cost is calculated individually after analyzing the technical specification and design. Typically, the first 2 weeks are spent on design, after which we finalize the timeline and budget.
Order turnkey development — we will evaluate your project in 2 business days and propose the optimal architecture. Contact us to discuss your task: we guarantee code quality, compliance with App Store Review Guidelines, and experience with projects of any scale. Get a consultation — we will help you choose the right stack and avoid common mistakes at the start.
