Flutterflow: hit or miss?
Quenching our thirst for new technologies, one of our engineering teams set out to uncover the potential of FlutterFlow - a promising low-code / no-code platform. Our experience was a mix of discoveries, uncovering both its impressive features and areas needing work. Here’s what our journey through FlutterFlow taught us.
Ease of use: getting around
FlutterFlow greeted us with an inviting interface and tons of helpful documentation and samples. However, testing wasn’t as snappy as expected, taking a few minutes to start an emulator and 10-15 seconds to see our changes in effect. Compared to the default Flutter tools, the hot reload functionality allows you to see changes in less than a second.
Writing custom code within the platform was clunky as well; it just felt easier to use other tools like VS Code. As for the backend side: while there is very good integration with Firebase, it is not a plug-and-play system where things can easily be changed to another provider. Each provider requires the effort of the FlutterFlow team, so integrations need to be chosen carefully.
Overall, you can only use FlutterFlow properly if you know the Flutter framework as well. The only difference is that instead of coding the UI, you use drag & drop.
Development pipeline: where it stands
The built-in save feature and support for CodeMagic impressed us. However, integrating with repositories other than GitHub proved challenging. FlutterFlow locked us into specific versions - no choice in selecting Flutter or FlutterFlow versions. Testing different app environments felt like a miss, limiting our ability to test thoroughly.
Code quality and customisation
Naturally, the generated code is not the same as what we would write. It needs to be able to handle all scenarios dynamically, so we shouldn’t stare ourselves blind on how we should maintain ‘clean code’. However, we need to assess the possibility to continue writing in this code.
The exported code was dynamic but tough to maintain; it kept changing with every update. Moreover, our custom code could easily be overwritten if we would try to extend the generated code. While it makes sense from FlutterFlow’s perspective to keep everything dynamic, it makes the code a lot less maintainable - which is a big ‘no’ for us.
What we also found was the FlutterFlow Marketplace was scarce. For any extra functionalities, we needed to write our own custom code in combination with third-party packages found on pub.dev. As mentioned, it’s exactly this extra custom code that makes it an extra hassle.
The verdict: is it for you?
FlutterFlow works well for simple apps and prototypes with minimal native features. But for complex apps, it needs to catch up due to its limitations.
For design engineers, it’s great to visualise Flutter’s capabilities. As a no-code tool or for prototyping, it’s powerful. But for extensive app development, it’s not there yet due to limitations in functionality and maintenance.
But it’s important to notice that FlutterFlow marks a milestone in the low- and no-code movement. We do not doubt that more and more of these tools will pop up for app development. Today, it’s already an excellent tool to test and validate your ideas in a cheap and fast way. And just recently, they added a new feature to include a FlutterFlow flow inside an existing project - which just shows the team is working hard on improvement. So maybe, tomorrow, we might build an entire custom app suite with tools like FlutterFlow.