Porting a 75,000 line native iOS app to Flutter

Gary Hunter
Oct 2, 2018 · 7 min read
Porting into the night
  • is written in Objective C and Swift and the backend is Amazon AWS.
  • contains 75,000 lines of code as per cloc.
  • the main cross-platform development options, Xamarin and React Native, had deal breaking drawbacks (that’s another story).
  • Architecture
  • Community
  • Performance
  • Language
  • What’s Missing?
  • Conclusion

Lines of Code & Development Speed

When I embarked on the port I estimated it would take 6 man months. Well, the project is coming in ahead of schedule! For me, that’s fairly unusual.😀

  • 47 nib files
  • 92 View Controllers
  • An Android Studio shortcut Alt + Enter to insert or remove UI widgets (rows, columns, containers). See Tips for using Android Studio to develop Flutter apps. I assume there’s something similar in VS Code. This seems trivial but I can’t emphasise enough how useful this shortcut is. With Hot Reload and Alt + Enter I can whip up a screen in minutes or whimsically experiment with a UI.
  • Setting debugPaintSizeEnabled to true. This displays brightly coloured borders around all the UI widgets. I thought I’d need this more than I did but it’s invaluable when a layout problem does occur.

Architecture

For me, choosing an architecture involved:


Community

The open source community involved with Flutter is very diverse, very supportive and gives me hope for the human race (especially during these crazy times).


Performance

Overall, users doing internal testing were happily surprised at how ‘snappy’ the Flutter port was. No noticeable degradation in performance was reported when running the native iOS app along side the Flutter app on the same iOS device.


Language

Flutter uses Dart, a language that up until the recent surge of interest in Flutter, had languished outside of Google.

  • Automatic formatting means one less headache to worry about …and I like using a trailing comma to put parameters on separate lines.
  • Package management is simple.

What’s Missing?

Not too much.

  • I used a good third party logging framework in iOS called CocoaLumberjack. Haven’t found a replacement yet.
  • I used WKWebView in the UIKit framework to load and render local HTML files (e.g. Terms of Use, Privacy Policy). I couldn’t find a package to do this correctly in Flutter. I ended up using a package, html2md, to convert HTML to Markdown and another package, flutter_markdown, to render the Markdown.
  • I used the AVFoundation framework to combine scanning barcodes and QR codes and taking photos within a single non full screen view. I haven’t got the same fine grained control in Flutter although the camera package is good for photos and, separately, facundomedica has written a great scanning package, fast_qr_reader_view. On Android devices this package hooks up Firebase’s ML Kit to realtime images from the Camera package.

Conclusion

If you’ve read this far you won’t be surprised that I give Flutter a pretty resounding thumbs up.

  • Because of the way Flutter UIs are constructed I’m able to build new functionality in Flutter more quickly than in native code.
  • Testers have not reported any performance degradation when using the ported app.
  • The code base shared between the iOS and Android versions of the app is currently greater than 90%. I have yet to integrate Apple HealthKit or Google Fit but don’t expect that percentage to drop too much.

Flutter Community

Articles and Stories from the Flutter Community

Thanks to Gary Hunter.

Gary Hunter

Written by

Native iOS & Flutter developer. https://twitter.com/Gazza500

Flutter Community

Articles and Stories from the Flutter Community