Recently, there has been a lot of talk about the cross-platform app development framework Flutter, and you might be wondering whether this framework is right for your next app. I have been working with Flutter for over a year and have created a few prototypes apps, one launched app, and another app releasing soon. Through my journey, I have been able to see many of the strengths and weaknesses of creating an app with Flutter. With this experience, I have compiled a set of four questions to help you decide if you should use Flutter for your next app.
1. What Is the Scope of the App?
First consider what features will be going into the app. Flutter’s greatest strength is the ability to develop beautiful user interfaces (UI). The framework gives you significant control over how the app looks and makes creating heavily customized UIs simple. The framework also aims to provide 60-frames-per-second animations, so apps look and feel very smooth to the user.
Another major strength is that the framework allows for cross-platform development. This means you only need to write the app on one platform. On the other hand, if your app requires some bleeding edge features like augmented reality or relies heavily on app background processing, then Flutter might not be a good choice. Technically, you can do anything you could on a native app as Flutter allows you to call native code, but the overhead is not usually worth it when you have to write a lot of code natively.
In practice, if your app leans more into photo processing, augmented reality, etc., using Flutter would not be beneficial. But if your app is an ecommerce app, customer portal, etc., where the purpose of the app is a positive front-end experience for customers and most of the back end will be handled on a server, then Flutter is a great choice.
2. What Is the Developer’s Willingness to Learn?
The next question centers on whether your developers can learn Flutter. Flutter is written in Dart, which is a language similar to Kotlin and Swift. There are very few Dart developers in the market, so there is a high probability that the developers on your team will have to learn Dart. On top of Dart, the developers will need to learn the Flutter framework. While this seems initially daunting, in reality this is not a huge barrier. If the developer is familiar with Java, Kotlin, Swift, C# or C++, then learning Dart should be very easy as the language is fundamentally similar.
Flutter is very easy to learn because there are a lot of learning materials available online in the form of videos and articles. Both Flutter and Dart are supported by very good documentation, which helps during the learning process. The main consideration with this question is whether the developers on the team are willing to learn this framework. One month of focused learning from an experienced mobile developer should be enough for them to be very comfortable coding in Flutter. If the developers on your team are willing to learn, then you should consider this framework as many developers have found this language easy and fun to learn.
3. How Much Time Is Planned for the Project?
The next consideration is the project timeline. In Flutter, a lot less code is needed to achieve the desired results. On top of this, Flutter also has a lot of great development features that aid in rapid development. The foremost of these is hot reloading. Hot reload allows code changes to be visible on the device instantly. During native development, after making changes to the code, the app usually needs to be rebuilt and deployed to the device. This process can take up to a few minutes. When the app is deployed, the developer has to navigate to the page where they want to see the results of their code changes. When the code changes with hot reload, the app updates and will stay on the same page so changes on the device are immediately visible. This changes the iteration time from a few minutes to a few seconds.
If your app is going to be developed for both iOS and Android, then the cross-platform nature of Flutter will save a lot of developer hours. Based on how platform specific you want the app, you can reuse up to 70 to 90% of the code. Realistically, you will probably be able to reduce the number of development resources by about 30 to 40%. When selecting the right developers, having at least one developer familiar with Android and one developer familiar with iOS will be beneficial to your team, as you will need people to handle native code and platform-related problems. In general, Flutter apps will be developed faster and require less resources than their native counterparts.
4. How Much Risk Will the Project Allow?
The last factor to consider is how much risk the project allows. Flutter is a new platform, so there are unknowns that could come up when dealing with the framework. This includes issues within the framework, with specific devices, and with specific native features. There is also a lot left to learn around best practices and ideal architecture for this framework, but that will come with time as developers find the best ways to create apps in this framework.
There is also the possibility that your team will need to write some custom functionality as there might not be tools available to do what you need. A lot of these problems are mitigated by the amazing open-source community working behind Flutter. The Flutter team has frequent releases with many bug fixes and features, and the community has released a plethora of libraries that can do almost everything you need.
For reliability, Flutter comes with UI testing and unit testing, and there are several third-party continuous integration and delivery (CI/CD) pipelines available. Considering all of this, there is still a risk when using something as new as Flutter. If your development cycle can bear some of the risk of an immature platform for the potential benefits, then Flutter would be a good choice.
These four questions should help you navigate through your app development journey and guide your decision about Flutter. If you have additional questions about Flutter or need help with an implementation, feel free to reach out at firstname.lastname@example.org.