Why Swift for iOS
Native performance, native UX, native safety
The Problem
Mobile apps are intimate. Users hold them in their hands, use them dozens of times a day, and expect them to feel like part of the operating system—not a webpage in disguise.
Cross-platform frameworks promise "write once, run everywhere." The premise was reasonable: humans are slow, maintaining two codebases is expensive, so accept the abstraction tax.
AI-assisted development breaks this premise.
When AI can generate platform-native code as easily as cross-platform code, the calculus changes. The question shifts from "can we afford two codebases?" to "can we afford runtime dependencies we don't control?"
React Native means depending on Facebook's bridge. Flutter means depending on Google's rendering engine. Both mean:
- Waiting for framework updates when platform APIs change
- Debugging across framework + platform + native boundaries
- Accepting performance overhead for abstraction you no longer need
- Trusting that the framework vendor's roadmap aligns with yours
For Converge, the mobile app handles business-sensitive decisions. Users need absolute confidence in responsiveness, security, and reliability. This isn't a content app—it's a control surface for commitments and obligations.
Current Options
| Option | Pros | Cons |
|---|---|---|
| React NativeJavaScript/TypeScript with native bridge. |
|
|
| FlutterDart with custom rendering engine. |
|
|
| Swift + SwiftUIApple's modern language and declarative UI framework. |
|
|
Future Outlook
Apple is investing heavily in Swift. SwiftUI is becoming the primary UI framework. Swift 6 brings full data-race safety—compile-time guarantees against concurrency bugs.
The cross-platform premise is obsolete.
Cross-platform frameworks existed because human programmers are expensive and slow. Two native codebases meant twice the work.
AI-assisted development inverts this:
- Generating Swift and Kotlin in parallel takes the same time as generating one
- The "twice the work" problem disappears when AI does the work
- What remains is the abstraction tax—and you're paying it for nothing
The gap between native and cross-platform is widening:
- iOS 18 brings features that cross-platform frameworks won't support for months
- Apple Silicon optimization benefits native code directly
- Privacy features (App Tracking Transparency, on-device ML) work best with native integration
- React Native's bridge and Flutter's rendering engine are dependencies you don't control
For a business-sensitive app, the question is: do we want runtime dependencies between our users and their data?
The answer is no. We want direct control, no middleware, and the ability to use every platform capability Apple provides.
Our Decision
✓Why we chose this
- Native performanceNo JavaScript bridge, no Dart runtime, no abstraction layer. Swift compiles to native ARM code that runs directly on Apple Silicon.
- Platform integrationFace ID, Secure Enclave, App Clips, Widgets, Live Activities—we can use any iOS feature on day one.
- Swift's type systemOptionals eliminate null pointer exceptions. Value types prevent accidental sharing. Swift 6 eliminates data races.
- SwiftUI + CombineDeclarative UI with reactive data flow. State management is built into the framework, not bolted on.
- Developer toolingXcode, Instruments, and the Swift compiler provide a cohesive development experience optimized for Apple platforms.
×Trade-offs we accept
- Two codebases (no longer a blocker)We maintain separate iOS (Swift) and Android (Kotlin) apps. With AI-assisted development, this costs weeks, not months. The abstraction tax of cross-platform exceeds this.
- Platform-specific knowledgeSwift skills don't transfer to Android. But the skill is now "direct AI to write Swift"—not memorize UIKit APIs.
- SwiftUI limitationsSwiftUI is powerful but newer. Some complex UIs still require UIKit. We use both where appropriate.
Motivation
Converge handles business-sensitive decisions on mobile. Users approve commitments, review obligations, and authorize actions from their phones.
Eliminate dependencies you don't control.
React Native puts Facebook's bridge between your app and the user. Flutter puts Google's Skia between your app and the screen. Every layer is a dependency. Every dependency is a risk.
With AI-assisted development, the cost of native drops dramatically. The question becomes: why accept dependencies when you don't have to?
This demands:
Maximum security — Native Keychain, Secure Enclave, biometric authentication. No JavaScript runtime anywhere near credentials.
No middleware — Direct API calls to Apple frameworks. No bridge, no runtime, no vendor lock-in.
Platform trust — iOS users expect apps to behave like iOS apps. Generic cross-platform UX erodes trust in business applications.
Swift gives us all of this, plus a language that aligns with our values:
Correctness over convenience — Optionals, value types, and strict concurrency make bugs explicit.
Explicit over implicit — No null surprises. No hidden state sharing. No magic.
We chose native because our users deserve native quality—and because we can.
Recommendation
For business-sensitive apps: Go native. The security, performance, and control benefits far exceed the "cost" of two codebases—which AI has reduced to near zero.
For new projects: Question the cross-platform assumption. It solved a human productivity problem that AI has already solved differently.
For existing React Native/Flutter apps: Evaluate rewrite cost with AI assistance. Removing runtime dependencies may be cheaper than you think.
For teams: The skill shifts from "can write Swift" to "can review Swift and understand iOS patterns." AI handles syntax; humans handle architecture.
At Converge, iOS is Swift + SwiftUI. No React Native wrappers, no Flutter layers. Zero dependencies between our code and the user. Native all the way.
Examples
import SwiftUI
struct ObligationView: View {
@StateObject private var viewModel: ObligationViewModel
@Environment(\.dismiss) private var dismiss
var body: some View {
VStack(spacing: 16) {
// Amount display with currency formatting
Text(viewModel.formattedAmount)
.font(.system(.largeTitle, design: .rounded, weight: .bold))
// Due date with relative formatting
Text("Due \(viewModel.dueDate, style: .relative)")
.foregroundStyle(.secondary)
Spacer()
// Approve with biometric authentication
Button("Approve Obligation") {
Task {
await viewModel.approveWithBiometrics()
}
}
.buttonStyle(.borderedProminent)
.disabled(viewModel.isProcessing)
}
.padding()
.alert("Error", isPresented: $viewModel.showError) {
Button("OK", role: .cancel) { }
} message: {
Text(viewModel.errorMessage)
}
}
}SwiftUI's declarative syntax makes UI state explicit. @StateObject manages the view model lifecycle. Biometric authentication is a single method call to the native API. This code feels like iOS because it is iOS.