Lessons learned from migrating a native iOS app to Flutter

Dependency Hell

The Flutter HttpServer and WebView are the two most important dependencies of my app. Without one or the other, my app will simply not work in that environment. From my experiences with iOS and CocoaPods, these days I look at every dependency as a technical debt: You borrow someone’s code or functionality, and one day you might have to pay for that.

Any piece of code that is not your own and that your app depends on adds to the technical debt of your app.

Personally, I consider WebView and HttpServer to be core parts of the Flutter technology stack as they are both developed and supported directly by the Flutter team and not some third party. (I will spare you the gruesome details of when I experimented with a third-party WebView for Flutter as an alternative.)

Therefore I was quite surprised that they seemingly received so little love from the Flutter team. I guess that either the current team at Google is just not big enough to pull off a project like Flutter (8,230 open issues as of today) or their priorities lie elsewhere. But it did inspire me to look at the dependencies of my Flutter app in general and compare them to the native Swift version of my app. Here’s the gist:

Native iOS (Swift)

AEXML was needed to parse some XHTML files as the native iOS SDK does not provide a DOM parser. The second library allowed me to use the popular FontAwesome icons in my app.

Flutter

• cupertino_icons
• HTTP
• provider
• shared_preferences
• font_awesome_flutter
• xml2json
• path
• path_provider
• mime
• flutter_web_browser
• webview_flutter
• url_launcher
• geolocator
• geocoding
• map_launcher
• wakelock
• device_info
• package_info
• scrollable_positioned_list
• in_app_review
• share

OMG! What do I need so many packages in Flutter for? Well, being an app and not an ebook, I had added some additional features and services to my native app: an online search for professionals in the area using a third-party API, displaying some information about the user’s current location using geolocation and reverse geocoding to help guide emergency services, and a speed dial for emergency phone numbers. Each feature needed some specific function from the native platform SDK — like geolocation, geocoding, triggering a call, or preventing sleep mode while the app was open. On top of that, you have basic functionality that you will find in any decent app: asking the user for a review on occasion, allow to share content with other apps, launch URLs, open a map app at a specific location, or access some information about the local device and operating system.

While iOS and Android provide most of these functionalities in their native SDKs out of the box, cross-platform solutions have to provide a bridge, package, or plug-in for every single one of them. And in the case of Flutter, they have to be implemented in three languages each: Dart, Swift/Objective-C, and Java/Kotlin.

Your Flutter app will depend on countless external libraries to allow you to offer the same functionality as a native app. The functionality of your app, therefore, depends on many unknown parties with different agendas, time constraints, and motivations for development. The technical debt of your app will increase with each plug-in that you use.

from Hacker News https://ift.tt/3qgDyD5