4. Evaluation

Caveat; the following is pretty opinionated and limited to my (time-boxed) experience with building the flutter app in this repository, as at Sep 2018.

Benefits

• your hitting x2 platforms not one (obviously)
• native UI performance with smooth animations
• hot-reload really does accelerate the development cycle, avoiding lengthy app restarts
• don't need to be an iOS/Android expert and can avoid a large number of platform specific concepts, e.g. Storyboards, View controllers, lifecycles (iOS) or Activities, Intents, Fragments (Android)
• composing apps from pre-built widgets results in rapid development
• the (Material design) widgets are feature-rich, implementing common UI patterns you can re-use (e.g. sticky/stretchy headers, hero animations)
• the layout model should be familiar to web developers and reactive paradigm to most
• Dart is easy enough to pickup, if your familiar with Swift/Kotlin or Java
• Documentation is good and there’s lots of free resources available to up-skill
• Google seem heavily invested in it (used internally/ battle tested)

Limitations

UI Limitations

Flutter renders its own UI, it doesn't use components provided by iOS/Android SDK's. A couple of limitations arise from this:

• missing UI components, the most notable being Maps and inline Web views
  • we can use plugins to open native maps/ web views, but these are presented in a separate view controller (iOS)/ activity (Android), which may not align with your design requirements
• limited number of Cupertino widgets
  • probably as expected, the Material design components are far more mature than their iOS counterparts
  • this is an issue if you want to build an app that closely conforms to the iOS look and feel
  • also, the current widget implementations aren’t pixel perfect replicas of those provided by the iOS SDK
• when the OS updates its UI, the flutter team (or open source community) need to play catchup
  • e.g. when Safe areas were introduced in iOS
• we can’t use the vast array of open source Swift/Java UI components, within the flutter canvas

Cross-platform Limitations

Sometimes you need to dig into platform specifics, you will need some level of understanding and experience with both iOS and Android development, for example;

• set a splash screen and app icon
• using iOS simulators and Android emulators (installing, launching, configuring, etc.)
• debug build issues
• deploy to app stores
• build your own plugins

Plugin Limitations

Plugins are key gap-fillers for native features that flutter can’t offer out of the box;

• most plugins are written by 3rd parties, as with any open source dependency, the quality varies, risk is higher vs depending directly on Apple/Android SDK
• plugins often don’t expose the full native API
• depending on 3rd party to keep plugins up to date or fork them yourself

Adoption Limitiations

• initially I thought the learning curve would be pretty steep, as you need to learn a whole bunch of widgets (classes) and their attributes;
  • I spent ~1 day getting familiar with the core concepts and Dart basics
  • took about ~2 days before I felt comfortable putting together a functional app (understanding which widget to use takes a fair bit of trial and error)
  • spent ~2 days building the POC in this repository
• Dart isn’t a particularly well known language, although coming from Swift, the learning curve wasn’t that bad and I would imagine the same for anyone coming from Java/Kotlin. The perception of using a proprietary language however may be off-putting to developers

Tooling Limitations

• it’s all code, there’s no official visual tools to help you construct UI’s
  • hot reload helps, but your testing against a specific device vs being able to switch between devices at design time, as you can with Storyboards (iOS)
• tooling can be a bit buggy, e.g.
  • hot reloading doesn’t always work
  • sometimes you need to stop, delete the app then re-run, to ensure clean state
  • flutter clean is your friend

OS Support Limitations

• iOS 8 and above
• Android 4.1 and above
• widgets are responsive to layout changes, but Tablets are not officially supported

Readiness

Use-cases where I would consider using flutter

• with clients open to using emerging (higher risk) technologies for potential savings
• where budget limitations mean building pure native is not a viable option
• for internal, non customer facing apps, proof of concepts and throwaways
• for customer facing apps, where the design requirements can be negotiated
• for teams with limmited mobile app experience

Use-cases where I wouldn't consider using flutter

• when the design requirements dictate a pure iOS look and feel
• where maps are the primary app feature or there are embedded web view (hybrid) requirements
• for apps which require Tablet support
• for teams without any mobile app experience
• when your targeting a single platform