Flutter to Native Code Migration: Why? | 1/5

After being a Flutter developer for years, I recently challenged myself to rewrite two of my Flutter apps into fully native Android (Kotlin) and iOS (Swift) versions using Jetpack Compose and SwiftUI respectively. I kicked things off with SongLib, a church song library app, and midway through, I also began working on SwahiLib, a Swahili dictionary app (Kamusi).

Juggling both projects taught me a lot about platform nuances, UI patterns, and managing shared logic across native ecosystems. Now, both apps are live on Google Play and the App Store! In this series of articles, I share the complete process, key insights, and what I'd approach differently to help others considering the same journey from Flutter to native development.

---

Introduction: Why Rewrite a Flutter App?

1. Need for a new Challenge, after the initial Flutter success

When I developed SongLib and SwahiLib back in Covid time, I chose Flutter for its powerful ability to create apps for both Android and iOS from a single Dart codebase. The framework's rapid development cycle enabled efficient creation of functional apps without the need for separate platform-specific codebases. But as a person who loves new challenges (I want problems) I started thing about going native for these two apps.

2. Mentorship-Driven Learning

As a mentor frequently helping others with mobile development, I have been regularly debugging and enhancing Android apps written in Kotlin and Java. These hands-on experiences, including reviving old Java projects and modernizing Kotlin applications, sparked curiosity about native development and revealed gaps in expertise that could limit my mentoring effectiveness.

3. Professional Skill Expansion

My decision to rewrite my Flutter apps into native code was also driven by my desire to become a more versatile developer capable of providing comprehensive guidance across Flutter, Kotlin, and Swift. By mastering native development, I am aim to strengthen hands-on mentorship abilities and remain competitive in a field where diverse technical expertise is increasingly valuable.

4. Personal Technical Challenge

When I started working with Flutter I was forced there by the steep learning curve that Objective C demanded if I was to develop iOS apps. I relied on my friends’ Macs to build my app for iOS which means to learn Objective C I would need to own a Mac so that I could spend quality time to learn. Over the years I was able to own a Mac on which now Xcode is installed and has been lying dormant except maybe when am building my app on iOS.

5. Tapping into the rich ecosystem of Android and iOS

Native development unlocks access to the full spectrum of platform-specific features and optimizations that may be limited or less efficient in cross-platform frameworks. Android's ecosystem offers advanced capabilities like highly customizable push notifications with rich media and actions, robust background processing through WorkManager and foreground services, interactive home screen and lock screen widgets, and significantly smaller app sizes due to platform-optimized compilation. iOS provides sophisticated notification systems with custom UI extensions, background app refresh capabilities, Today widgets and App Clips for lightweight functionality, and efficient app thinning that delivers only necessary resources to users' devices.

By developing natively, apps can achieve optimal performance with smaller APK/IPA sizes, implement platform-specific user experience patterns that feel natural to users, and leverage immediate access to new OS features as they're released, all while maintaining the performance benefits of platform-optimized code compilation.

Trade-offs of Moving from Flutter to Native Development

Advantages:

• Superior Performance: Direct access to platform APIs without Flutter's rendering layer, resulting in faster app startup times, smoother animations, and optimal memory management

• Significantly Smaller App Sizes: Native compilation produces smaller APK/IPA files compared to Flutter's bundled framework, with platform-specific optimizations like Android's ProGuard and iOS's app thinning

• Full Platform Feature Access: Unrestricted use of advanced capabilities like customizable push notifications, robust background processing (WorkManager/Background App Refresh), interactive widgets, and deep system integrations

• Authentic User Experience: Native implementation of platform-specific design patterns (Material Design for Android, Human Interface Guidelines for iOS) that feel natural and familiar to users

• Rich Ecosystem Access: Immediate availability of cutting-edge platform features upon OS release, extensive native libraries, and seamless integration with platform services (Google Services, Apple ecosystem)

Disadvantages:

• Doubled Development Complexity: Requires learning and maintaining expertise in multiple languages (Kotlin/Java and Swift), development environments (Android Studio and Xcode), and platform-specific concepts

• Significant Maintenance Overhead: Maintaining separate codebases doubles development time, testing requirements, and bug fixing efforts across platforms

• Increased Development Costs: Need for Mac hardware for iOS development, multiple development tools, and potentially separate development teams or extended timelines

• Platform Fragmentation Challenges: Android's diverse device ecosystem and iOS's hardware variations require extensive testing and platform-specific optimizations

• Slower Feature Delivery: Implementing features twice means longer development cycles compared to Flutter's single codebase approach, potentially delaying time-to-market for new functionality

---

In this article I explain why I took this path as well as the trade offs that came with it just in case there is someone looking to do this one day. I next article I will be talking about the code itself from an setup perspective.