FlutterFlow overview: a look at the low-code platform's features, advantages, and limitations

A few years ago, launching a mobile app meant months of development, the work of several specialists, and a high business entry barrier. 

Against this backdrop, no-code and low-code platforms appeared to be a solution: fast, inexpensive, and «almost no code». FlutterFlow has become one of the most prominent examples of this trend, particularly among startups and non-technical teams.

In this article, we will take a closer look at one of the most popular tools of this type, FlutterFlow, and look at what tasks it simplifies and where difficulties may arise.

Users can access a variety of standard widgets, including simple markup blocks, scrollable lists, and more complex tools such as PIN entry forms, rating systems, and digital signature fields.

In addition to standard buttons and cards, the system easily implements graphics and animations, such as Rive and Lottie. Along with many other features, this allows you to quickly assemble almost any popular application function without delving into technical details.

Also, the set of preset parameters in the sidebar of the widget configuration may be limited, despite the possibility of more detailed configuration. If you need to change smaller details, you will either have to accept what is in the panel, or write your widget from scratch, which makes the visual designer meaningless.

FlutterFlow also provides for an adaptable interface, however, more complex layouts will require a build-up of conditions or duplication of elements, which can negatively affect performance and user experience.

Working with data and API

FlutterFlow provides embedded and external solutions for working with data. The platform supports direct integration with Firebase Firestore and Supbase as a BaaS (Backend as a Service), a ready—made cloud backend that takes care of data storage, user authentication, database management, and server logic without having to write and maintain its own server. 

Flexible work with any external REST API is also available through creating your own queries, implementing simple offline logic, and storing data locally on the user's device.

Ready-made integrations and third-party services

The ecosystem of the platform is expanding due to ready connections to popular external services. This includes integrations for payments and monetization (Stripe, RevenueCat, etc.), analytics services, as well as the ability to embed any third-party logic through writing your own actions on Dart.

Application functionality

FlutterFlow allows you to customize key application functionality without code. This includes designing navigation with routes, transitions, and deeplink schema processing, visually building business logic through a system of actions and flowcharts, and configuring push notifications through integration with Firebase Cloud Messaging.

Platform features

The platform uses the capabilities of the Flutter framework, which is initially focused on cross-platform development and allows you to build applications for iOS, Android and Web from a single code project. FlutterFlow, in fact, does not violate this model, but only provides a visual interface for working with it.

Real-time testing is also available directly in the browser or on a connected mobile device. Support for desktop platforms (Windows, macOS, and Linux) is currently in the alpha stage and might be unstable.

Version control and source codes

For teamwork and quality control, FlutterFlow provides tools for collaborative development: a comment system, built-in version control, and the ability to view the revision history. A key feature is the ability to export the entire project to clean, readable code on Flutter (Dart), which paves the way for further manual development in any IDE.

Deployment and publication

The platform greatly simplifies the process of deploying and publishing an application. From the web interface, you can generate production builds for all platforms, automatically host the web version on Firebase Hosting, and prepare App Store and Google Play packages via built-in pipelines. For advanced scenarios, you can export the source code for integration into your own CI/CD processes and automate delivery via connection to GitHub.

FlutterFlow Application Architecture

Although FlutterFlow offers a simple and convenient way to build the UI and configure some application features, it prevents developers from designing a flexible and scalable framework that can grow with the product's complexity. 

Creating an application using a low-code solution may be appropriate in the case of a POC (Proof Of Concept) or a simple MVP, but as soon as it comes to something bigger and more complex, the chance of running into problems and limitations is quite high. 

It is worth noting that after moving beyond the framework of the platform, support can cause considerable difficulties, since the project itself is strongly tied to a low-code approach and it may be difficult for many developers to navigate and debug such code.

The FlutterFlow application component organization approach can be described as a component-based architecture with MVVM (Model-View-ViewModel) elements, however in a simplified form. 

Widget Structure and Action Flow

The Data, Domain, and Presentation/UI layers are not separated, and each widget is built as a two-class bundle: a model class (logic and local state) and a widget class (interface). 

Here, the main unit is the visual component and its actions, rather than the feature or module. The logic of the widget is described using an Action Flow with an imperative approach, which creates a sequence of code blocks.

On the one hand, it's easy to build it, but debugging and extending or changing the logic can be difficult.:

• The chain of actions allows you to include navigation, status updates, API calls, and UI display logic, which already complicates debugging a separate section of logic.
   
• Changing existing or adding new blocks of logic may require changing and adapting the entire chain of actions, and with complex business logic with many branches, everything turns into difficult-to-read code.
   
• If necessary, you will have to either copy-paste the code or put the logic in separate blocks, but they are not so flexible as to save unnecessary changes in the future.
   
• In some places, there is no single data source, as data is requested in multiple widgets, and the business logic is scattered across different buttons and triggers.

State management

There are two options for state management: local and global. The first option is limited by the scope of a particular component or screen. Global state management stores shared data that needs to be accessed from anywhere in the application and is used on top of the entire application.

This implementation has a number of disadvantages:

• Logic lacks encapsulation and a single place where the rules of system behavior and transition from one state to another would be described. One stream of logic can interfere and spread across several models.
   
• Over time, the global state turns into a set of variables that becomes difficult to control and monitor. Any change can trigger a chain of unpredictable updates throughout the application.
   
• The lack of granularity leads to an unnecessary redrawing of the interface. And if there are animations or complex elements on the screens, then this can cause micro-friezes in the application.

Communication with data and services

As already noted, there is no division of the project into layers, but two main parts can be distinguished in the structure: frontend and backend. The code has a strong attachment to services and a connection between widgets and the data layer:

• Widgets request data from APIs (such as Firebase or Supabase) directly, creating queries for the database during initialization, for example. In some cases, projects may require a domain layer or repositories, which FlutterFlow omits.

• FlutterFlow creates custom wrapper classes that are used in both UI and logic.
• Services often exist in a project as singletons, which kills the possibility of free testing of business logic.
• Directly calling services leads to a lack of dependency inversion, which adds complexity to project expansion and reduces flexibility.

What is the limitation of the FlutterFlow application architecture?

Based on the information above, it is clear that the project structure violates the Single Responsibility Principle (SRP). There are no layers of abstraction, and the components are tightly coupled.

No-code and low-code solutions show good performance at the MVP stage, but when developing a product and moving to long-term operation, it is important to plan in advance not only the evolution of the architecture, but also the possible migration from the FlutterFlow platform itself to a more flexible and controlled stack. Without this, the limitations of the tool can become critical over time.

The LighTech Experience

In the history of our company, an example of such a «mixed» project is the Spirit Up application, which was originally created using FlutterFlow, but later moved to the Dart development stage and worked directly with the codebase. 

The first thing the developers faced was the difficulty of code readability and finding solutions that would minimally involve changing existing functionality. 

Rewriting the structure of a large project that has already been built is a time-consuming, difficult, and expensive task that is clearly unnecessary in the context of an already published application. While this does not make development impossible, it turns it into a process of constantly overcoming obstacles.