Why I Started Using Flutter Alongside Native iOS

Background

I've been building iOS apps with Swift and UIKit since 2016. I love the Apple ecosystem — the tooling, the design guidelines, the performance. So when people asked me about cross-platform frameworks, I was always skeptical.

But in 2024, a client project required both iOS and Android delivery on a tight timeline. I decided to give Flutter a serious try.

What Surprised Me

The Good

• Hot reload is amazing — Coming from Xcode's build times, Flutter's sub-second hot reload felt like magic. It fundamentally changes how you iterate on UI.
• Widget system makes sense — Once you get past the nesting, Flutter's composable widget tree is actually quite elegant. It's declarative, similar to SwiftUI.
• Dart is easy to pick up — If you know Swift, Dart feels familiar. Null safety, async/await, strong typing — the concepts translate well.
• One codebase, two platforms — Shipping to both iOS and Android from a single codebase is a genuine productivity multiplier for smaller teams.

The Not-So-Good

• Platform-specific polish — Getting that native iOS "feel" requires extra effort in Flutter. Scrolling physics, navigation patterns, keyboard behavior — these details matter.
• Package ecosystem — While pub.dev has a lot, the quality varies. Native iOS libraries via CocoaPods/SPM are generally more mature.
• Xcode is still needed — You still need Xcode for signing, capabilities, and debugging platform-specific issues. Flutter doesn't replace it entirely.

My Current Approach

I now use Flutter for projects that need both platforms and native Swift for iOS-only apps or projects that require deep Apple framework integration (ARKit, HealthKit, etc.).

It's not about choosing one over the other — it's about using the right tool for each project.

Key Takeaway

Don't be tribal about frameworks. Learn multiple tools, understand their tradeoffs, and pick what serves the project best. The best developers I know are pragmatic, not dogmatic.