Why are we embracing Flutter in our team?The reasons we decided to add Flutter to our journey
Last updated: December 18, 2019
The Simple answer is to make our life easier, for details keep reading!
I work at a start-up. And like any other start-up, it has that typical start-up workload and crazy requirements that we need to meet along with
- Faster Delivery .
- Lack of resources.
- Frequent feature request.
- Experimental features.
- And off-course, technical debt.
we have two codebases for two platforms (Android, iOS) written in Objective-C, Java and partially(new features) Kotlin and Swift. And those legacy codebases are hard to manage, fix bugs or to modify. It is much easier for the team to write a new and better one than carrying on with the legacy code.
For a fast delivery and frequent request for new features, there are some problems faced by all the start-up programs where people are usually working on different platforms. when two-person working on two different platform tries to develop the same feature, usually the features end up looking nonidentical. Most of the time these same features from different platforms don’t get finished at the same time and fail to meet the deadlines, thus a delay in the release date! it’s not that they lack very good communication, planning or a good amount of effort, still, it happens.
here’s why :
- Two solution always seems a bit different after implementation due to human biases.
- Two teams produce two different kinds of bugs.
- Individually they solve each bug, costing more time.
- QA team invests triple the effort on each platform to find bugs, test functionality, and match between the platform so check if both teams could achieve the same thing or not.
That results in prolonged development time, delay in the release day (making the product and commercial team unhappy).
A unified codebase that will serve both platforms so that
- All the team members can work on the single codebase to implement a single feature to avoid human biases reducing the number of bugs and feature mismatch.
- Lesser QA team effort.
- A lot less development time.
- A lot less effort on maintenance and bug fix.
- Fast feature request full-fill.
But the question is, there are many options to choose from but which one should we choose?
Ionic and Xamarin weren’t a good candidate. We tried out React-native a bit last year and decided not to continue for the following reasons:
- Performance lag.
- Can’t render complex shadows.
- Buggy ( at least it seemed to me).
- It’s hard to write and debug JS code( for a dev who’s background is Java, Swift or strongly typed language)
Flutter to the rescue!!!
I was skeptic at first but then did some demo project, read some case studies on other companies. Finally, embraced it and decided it’s a perfect candidate.
- Marvelous performance.
- Declarative UI code that helps in faster and easier implementation of modern reactive features.
- Great tooling.
- Able to add to existing Android and iOS projects as a third-party dependency.
- Fast development.
- UI rendering is awesome.
How exactly will the transition follow? there will be three stages:
- Identification Stage: At first we need to identify which are the existing features that need to be written with Flutter (legacy code or the buggy ones). And off-course, new features that will be developed in Flutter.
- Transition Stage: At this stage, we will be converting legacy or buggy native codes to Flutter. In this stage, APK/IPA size might be a bit bigger because of many factors ( discussed in detail on my next blog). (duration: 3 - 6 months)
- Final Stage: At this stage, all the native codes will be converted to Flutter making all the codes to be dart code.
This is the initial plan, I’ll write another technical blog after a few days about the progress and difficulties that we could face and how to solve them.