Category: Blog

Flutter unlocks a new era of engaging, well-crafted, and visually stunning TV apps, enabling businesses to reach millions of devices with a single codebase.

Platform support

Flutter supports several officially endorsed platforms maintained by Google: Android, iOS, Linux, macOS, Windows, and the web. Each package in the Flutter ecosystem indicates which platforms it supports.

LG and Samsung have extended the Flutter SDK to support their respective TV platforms. In practice, this means that instead of using the regular flutter command, developers should use flutter-webos for LG TVs or flutter-tizen for Samsung TVs.

Both manufacturers are also building their own ecosystems of packages tailored for webOS and Tizen.

Android TV

While there’s no official Flutter support for Android TV, it’s still a good old Android device, and Android is one of Flutter’s core platforms. That means building and running apps for Android TV is as straightforward as any other Android app. To optimise the experience, you may need to add a few new values to the AndroidManifest to ensure the app is recognised as a TV app and that the icon appears correctly on the home screen.

Samsung Tizen

Flutter-Tizen is an extension to the Flutter SDK designed to build apps on Tizen-powered devices, including TVs. It supports Tizen 6 and later (starting with devices released in 2021), and the SDK is officially supported by Samsung.

LG webOS

In 2024, LG announced their support for Flutter apps on the webOS platform. That same year, they hosted a TV app hackathon, where all three winners built games for LG TVs using Flutter.

LG is not only enabling Flutter development for webOS—they’re rewriting their own core webOS TV apps with Flutter. A public SDK release is expected in the first half of 2026.

Codemate is LG’s leading partner in developing the webOS Flutter SDK Beta. From our experience, the SDK offers an excellent opportunity to add TV support to existing apps or to build new apps from scratch. We have used Flutter webOS SDK extensively and can say that many apps can be built for TV with minimal effort – most things just work when you run the app on TV.

Apple TV

There’s no official support from Google or Apple for Flutter on Apple TV. However, Flutter enthusiasts maintain a custom Flutter engine with Apple TV support. This project is experimental, and package availability is a big question mark.

Challenges of building TV apps with Flutter

Supporting a new device category or screen size always comes with challenges. For example, properly supporting tablets or foldables is not just making sure the app works, but also making the user experience great.

Here are some of the challenges we’ve encountered when bringing Flutter apps for TV:

Adaptive UI and big-screen considerations

TVs are large, but that doesn’t always mean you should use all available screen space for content. TV content is viewed from a distance and is usually navigated with a remote. This sets some limitations on how the content is presented to the user.

DRM content

One of the biggest challenges is playing DRM content on different TV platforms. Each platform needs its own implementation of DRM video playback. Tizen and webOS have their own custom video player packages with DRM support, but not all DRM protocols are supported across platforms. You’ll need to choose the right video player package for each platform and ensure the app knows which one it’s running on.

Detecting the platform at runtime

Since not all TV platforms are officially endorsed, normal runtime checks and conditional imports don’t always work. During our tests, we used Flutter flavours to identify the current platform at runtime.

Real TV testing

It’s not always possible to test how well the app works on a TV platform using an emulator. It could be a lack of emulator support or a less realistic and less physical testing environment. Thus, we’ve used real TVs to test the app on Android TV, Tizen and webOS.

D-pad navigation

Imagine using an app on a device without a touchscreen. This is something that should be considered when building TV apps. Usually, TVs have remotes with directional navigation (also known as D-pad, a set of arrow keys to select an element and an OK button to confirm the selection). This part doesn’t always work well with Flutter, especially with multi-directional scrolling and custom components.

For webOS, the Magic Remote is treated as a mouse pointer, which triggers hover events and works out of the box in Flutter.

Platform overview

Platform	Status
Android TV	✅ Supported
Samsung Tizen	✅ Supported, SDK released
LG webOS	✅ Supported, SDK to be released
Apple TV	❌ Not supported

Flutter is no longer just about mobile — it’s stepping into the living room and onto the biggest screen in the house. With growing support for Android TV, Tizen, and webOS, developers have new opportunities to bring apps to the TV experience using the tools they already know. We’re excited to see Flutter’s future on the big screen unfold — and proud to play a small part in helping developers make the most of it.

Efficient technology backed by experience

Flutter’s appeal lies in its fast development pace and ability to support multi-platform delivery from a single codebase. For Moi, it enables a six-person team to manage and develop four applications – for iOS, Android, and Web – simultaneously.

– When I became team lead, our team size doubled, and so did the number of applications. With native technologies, we would’ve likely needed a much larger team, says Jussi-Tapio Lamminheimo (Jusu), the team lead.

Starting with Flutter’s early days, this team has been ahead of the curve – building one of the first commercial Flutter for Web applications, which was even showcased at a Google meetup.

– Flutter helps us streamline app management through one codebase. It also boosts team satisfaction, because developers genuinely enjoy working with it, Jusu adds.

Building a culture of ownership, openness and agility

The team includes developers Alex Lindroos, Hung Nguyen, Mikael Gousetis, and Iiro Pelttari, along with designer Petri Pystynen. While Jusu provides guidance, daily collaboration is driven more by shared ownership and results than hierarchy.

– We have a flat structure. If we have different opinions, we talk them through – and if needed, we vote. Everyone has a say, Alex notes.

Instead of following agile methods by the book, the team has crafted a workflow that suits their rhythm:

– We follow sprints and respond quickly to evolving needs, Mikael explains.

– It’s agile, but in our own way – we’ve taken the parts that serve us best, Iiro adds.

This flexibility thrives on trust, feedback culture, and transparency. The team proactively supports one another, tackles issues collaboratively, and values constructive feedback – making continuous improvement a natural part of their everyday work.

– We don’t blame – we solve things together, Hung explains.

– We’ve built deep trust. There’s psychological safety to experiment and grow, Iiro says.

Intentional team-building yields long-term results

What makes this team’s dynamic exceptional is not luck; it’s intent. Over the years, they’ve invested in team-building both during and beyond working hours: sharing knowledge, solving problems together, and strengthening interpersonal trust through openness and honest communication.

While not every team becomes a tightly bonded unit overnight, the practices behind this one – psychological safety, shared goals, respect for one another’s strengths, and mutual accountability – are replicable and valuable for any project team. And fostering this kind of team culture is exactly what we always aim for at Rebel.

In addition to investing in team-building, we also prioritise employee happiness and retention. On average, our team members stay with us for nearly seven years – a rare figure in our industry, and a key reason why strong, lasting team dynamics like these can truly develop.

A partnership built on trust and continuity

Working closely with the same customer over time deepens mutual understanding. Jusu and the team know Moi’s business environment, values, and communication styles inside out, which leads to faster decisions, stronger alignment, and better outcomes.

– Jusu understands Moi’s needs intuitively. That clarity helps all of us deliver more efficiently, Petri says.

Despite balancing new development with app maintenance across four platforms, the team maintains consistently high morale and delivery quality. Their openness to collaboration and shared accountability is a cornerstone of the partnership’s success.

– We’ve been working together for years, and the chemistry we’ve built enhances both speed and quality. We can tackle anything together, Jusu notes.

From early adoption to streamlined excellence

From the early days of Flutter to today’s mature, multiplatform solutions, this team has evolved with the technology, always seeking better ways to deliver value.

– Back then, we had to invent our own solutions. Now, we’re focused on refining the user experience and performance, Hung shares.

– Flutter gives us the flexibility and consistency we need across platforms. Our users get a native-like experience, and we work from one codebase, Mikael and Petri agree.

It’s not just about the tools – it’s about the team

At Rebel App Studio, we believe that great digital products are the result of great teams. Technology like Flutter enables efficiency, but it’s the way teams collaborate, give feedback, and take ownership that truly makes a difference.The team behind Moi’s applications demonstrates how intentional team-building, trust, and shared purpose can be turned into long-term value, not just for the team but for the customer too.

In this post, we take a closer look to key benefits of Flutter, Google’s cross-platform framework, and why it’s become one of the most exciting choices in modern app development. We’ll explore its benefits from the perspective of designers, developers, business decision-makers and of course, end users.

What is Flutter, in a nutshell?

Flutter is a modern, open-source framework created by Google and based on our experience, it’s often the fastest, most elegant way to build high-quality products today.

With one codebase, you can build:

• Android apps
• iOS apps
• Desktop apps for Windows, macOS and Linux
• Progressive web apps
• That’s a serious reach, all without juggling multiple tech stacks.

Read more: Moi Mobile – From young rascal to serious mobile operator contender

Of course, Flutter isn’t a silver bullet. It’s not the best solution for every use case – if you’re building a content-heavy blog or traditional web shop, there might be better tools. But when it comes to apps that need to look and feel good across different platforms, Flutter is hard to beat.

What are the key benefits of Flutter?

The benefits of Flutter go beyond just having a single codebase. It speeds up development, makes designing a breeze, and, most importantly, helps create apps that users love to use. Let’s look at benefits of Flutter through the lens of the people who matter most.

01 Designers love Flutter’s flexibility

If you’re a designer, Flutter is your playground. It gives you pixel-level control, which means your design vision can come to life exactly as intended, with no compromises. From sleek UI to smooth animations, Flutter gives you the tools to create consistently beautiful experiences across devices and platforms.

Because development with Flutter is fast, design iteration becomes easier, too. Want to tweak a prototype and test it with real users? No problem. The feedback loop is short, so it’s easier to fine-tune your design based on real insight instead of guesswork.

02 Developers get speed and control

One of the benefits of Flutter is that it is built for productivity. Thanks to features like hot reload, developers can see changes instantly, which keeps the workflow smooth and efficient.

It also includes everything you need to build high-quality apps, right out of the box:

• A huge library of ready-to-use widgets
• No compromise on visuals – customise existing widgets to your needs or build your own widgets easily
• Automated testing tools to keep things running smoothly
• And a thriving global community to lean on

In short: developers can do more, faster, and have fun doing it.

If you want to learn more about test automation tools, check out our test automation tools -blog series!

03 Business stakeholders value its speed and cost-efficiency

The sooner you can get your product to market, the faster you can start learning, iterating and growing. Did you know that with Media Group Keskisuomalainen, we launched 17 apps in just 3 months – thanks to Flutter’s rapid development speed. It allows you to ship faster, more frequently, and with a smaller team. The sooner you get your product to market, the sooner you can start learning, iterating, and growing. 

No need for separate teams for Android, iOS and web. One skilled Flutter team can cover it all. That keeps overheads low and delivery timelines short.

And here’s something that often gets overlooked: long-term maintenance costs. Native apps can become expensive to maintain, especially when iOS updates demand rework. Flutter’s architecture helps mitigate that by shielding much of your codebase from those changes.

04 End users just notice that your app feels great

Most users don’t care what your app is built with, but they do care that it works flawlessly, feels intuitive, and looks fantastic – no matter what device they’re using. 

With Flutter, you get:

• A consistent brand look across mobile, desktop and web
• A smooth, bug-free experience, supported by automated testing
• More time for developers to focus on building delightful features, not just the basics

All of which leads to happier users who keep coming back.

Let’s build something brilliant, together

There’s a lot that goes into building a 5-star app, and tech is just one part of the puzzle. For example, in a restaurant app, users might complain about delivery delays or missing mayo, not the app’s code. That’s why we approach every project with the full picture in mind.

With Flutter, we can move fast, stay flexible, and keep the focus where it belongs: on creating apps that users actually enjoy using.

At Rebel App Studio, our designers and developers work hand-in-hand to create seamless, user-focused experiences. Whether you’re still weighing your tech options or ready to dive into your next app build, we’re here to help.

Got a project in mind? Let’s chat.

Flutter offers great built-in support for internationalisation. If you’re unfamiliar with it, Flutter uses ARB files (JSON-like files), with one file per supported language in the app. The main ARB file contains all key-value string pairs used by the app, while the other ARB files replicate the same keys with values translated into different languages:

intl_en.arb (default):
{
 "@@locale": "en",
 "homePageTitle": "Home page",
 "buttonText": "Open next page"
}

intl_fi.arb:
{
 "@@locale": "fi",
 "homePageTitle": "Kotisivu",
 "buttonText": "Avaa seuraava sivu"
}

While the process is straightforward, mistakes can still happen. From forgotten strings to assumptions about how all languages work, let’s dive into the most common localisation issues developers encounter and how to fix them.

01 Don’t forget to add strings to ARB files

It’s easy to overlook adding a string to the ARB file. This can result in an inconsistent user experience:

const Text('System status') // Can't be translated to other languages

02 Translate everything: avoid overlooking key texts

Some developers assume that text like unit names (e.g. “km” for kilometres or “MB” megabytes) don’t need localisation. However, unit names may differ in languages that don’t use Latin characters: For example: 

• Greek: “km” → “χλμ” 
• Bulgarian “km” → “км”

Text("$calculatedDistance km") // Can't be properly translated

03 Keep your strings updated: No room for errors

It’s human to forget. When adding a new string to the main localisation file, it’s easy to overlook providing the corresponding translations. During development or even before building a release app, there’s often no reminder to ensure up-to-date translations.

Another common issue arises when existing localisations are not updated after changes to a feature. For example, if a feature is modified and its strings are updated, developers might adjust the main translation strings to match the new design but neglect to update the translations. This results in inconsistent user experience and misleading translations.

Additionally, not all strings need to stay forever. If a string is no longer used, it should be removed to reduce translation workload and keep the localisation files clean. 

04 English isn’t universal: adjust for language rules

Languages handle plurals in different ways, and assuming English pluralisation rules apply universally can lead to incorrect translations. For example:

final myString = cartItems.length > 1 ? “items” : “item”;

This approach may work in English but fails in other languages with more complex pluralisation rules. Just to show the issue: the code above doesn’t even work for the quantity of 0 in English. The solution is to always use plurals in ARB files, which are designed to handle such variations.

Additionally, programmatically constructed strings often overlook important linguistic features such as word order, grammar cases, punctuation, and pluralisation rules:

final myString = strings.question + items.length + "?";

 Instead, use localisable strings that accommodate these nuances. For example:

"message": "Would you like to remove {count, plural, other{{count} items} one{{count} item}}?"

This structure enables accurate translations that respect the grammar and pluralisation rules of the target language, such as:

"message": "¿Desea eliminar {count, plural, other{{count} elementos} many{{count} elementos} one{{count} elemento}}?"

To better understand the pluralisation rules across different languages, unicode.org provides a detailed table of plural rules. These variations highlight why it’s often better to rely on Flutter’s built-in localisation support rather than attempting to build a custom solution.

05 Manage plurals properly: avoid missing or extra rules

Flutter supports plural strings for all supported languages, but the rules for plurals vary widely. For example, English requires just two options to handle all possible plural forms:

"message": "{count, plural, other{{count} items} one{{count} item}}"

In contrast, other languages may need more plural options to account for their specific grammar rules. . For instance:

• Vietnamese uses only one option. 
• Irish requires five options.
• Arabic requires all six plural forms. 

Here’s an example of Arabic pluralisation:

"message": "{count, plural, other{{count} ceann} one{{count} cheann} two{{count} cheann} few{{count} cinn} many{{count} gcinn}}"

It’s important to avoid translating plural options that are not used in a particular language. Including unnecessary options increases the effort required to translate and maintain ARB files without providing any benefit. For example, normally English localisation does not need values for “zero,” “two,” “few,” or “many”, however it uses “one”, “two”, “few” and “other” as ordinals (values like “1st” or “2nd”).

06 Understand “One” and other plural forms

Despite their names, plural forms like “one” and “two” can apply to more than just the quantities of 1 and 2 in certain languages. For example, these forms may also apply to quantities like 21, 22, or even other specific quantities. Assuming “one” or “two” refers only to the quantities of 1 and 2 can lead to incorrect results:

"durationHours": "{count, plural, one{1 sat}..."

durationHours(1)  // Returns "1 sat" (correct)
durationHours(21) // Returns "1 sat" (incorrect)

The fix is easy: always use placeholders in plural strings to ensure the correct value is displayed:

"durationHours": "{count, plural, one{{count} sat}..."

This guarantees that the correct number is included in the output, respecting the pluralisation rules of the target language.

07 Define placeholder types for safer code

Specifying a placeholder type makes generated Dart code type-safe. For example, consider this string, which uses a placeholder but doesn’t define its type:

"key": "Hello, {username}!"

This will generate the following Flutter code:

String key(Object username) {
  return Intl.message(
    'Hello $username!',
    name: 'key',
    desc: '',
    args: [username],
  );
}

As you can see, the placeholder’s type is Object, which lacks type safety. To address this, you can explicitly define the placeholder type in the ARB file:

"key": "Hello, {username}!",
"@key": {
  "placeholders": {
    "username": {
      "type": "String"
    }
  }
}

This results in type-safe Dart code, ensuring only the correct type can be passed to the function:

String key(String username) {
  ...

By specifying types for placeholders, you reduce the risk of runtime errors and improve code robustness.

08 Account for text length: accessibility matters

The impact of text length on an app may not always be obvious. For example, limiting the text length in a Text widget can negatively affect the app’s accessibility:

return TextButton(
  onPressed: onPressed,
  child: const Text(
    'Add to cart',
    maxLines: 1,
  ),
);

If a user increases the text size in their device settings or if the app’s locale changes, the button’s label could become truncated, making it difficult or even impossible to read. Read more about the accessibility of Flutter apps in one of our previous articles here.

09 Keep ARB files clean and organised

While developers often strive to keep their code clean, ARB files are frequently overlooked—even though they are a crucial part of the app and eventually converted into Dart code.

Here are some common issues that can make ARB files and the generated Dart code inconsistent:

• Key naming conventions: Inconsistent naming makes the file harder to maintain.
• Empty @-keys: Keys meant for metadata but left empty create unnecessary clutter.
• Empty strings: Untranslated or placeholder strings can cause runtime issues.
• Redundant or unused @-keys: These add noise and increase maintenance overhead.
• Duplicated keys: Repeated keys lead to conflicts and confusion in localisation.

By addressing these issues, ARB files can be kept clean, improving the maintainability and reliability of the app’s localisation.

Tools to simplify ARB file management

How can one identify, fix, and minimise issues in ARB files? While not all problems can be automatically detected and resolved, many common issues are easy to spot with tools provided by the Flutter community.

ARB Editor is an official VS Code extension from Google that checks ARB files’ validity. It’s a great extension that also provides a set of snippets for creating strings, plurals and selects.

Rebellion by Rebel App Studio is a command line lint tool for ARB files. It ensures that all strings are properly organised and that ARB files are free from errors. It can catch issues like missing translations, unused keys, incorrect pluralisation, and inconsistent naming conventions. For example:

> rebellion analyse ./lib/l10n/

l10n/intl_fi.arb: all caps string key "key2"
l10n/intl_fi.arb: no @@locale key found
l10n/intl_en.arb: key "@key4" is missing placeholders definition
l10n/intl_fi.arb key "key3" is missing a plural value "one"
l10n/intl_en.arb key "key3" contains a redundant plural value "zero"
l10n/intl_fi.arb: missing translation for key "key_5"
l10n/intl_fi.arb: @-key "@key" should only be present in the main file
l10n/intl_en.arb: key "key_5" does not match selected naming convention (camel case)

8 issues found

Adding Rebellion to your CI/CD pipeline ensures potential issues are caught before they’re merged into the main branch, saving you time and preventing errors from reaching production. We’re continuously improving Rebellion, with plans to integrate lint rules directly into the IDE for even smoother development workflows.

Let’s connect!

Rebellion is built by developers, for developers, and we’re always looking for feedback to make it even better. If you have questions about ARB file management, localisation best practices, or how to integrate Rebellion into your projects, feel free to reach out to us.

A year of growth

2024 was a year of success for both Rebels and Flutter. With an increasing number of big production apps built using Flutter—including several developed by our team—we’ve seen the framework thrive. Rebel App Studioby Codemate now boasts a team of 100 skilled professionals and strong operations in Europe and the US. As part of a larger company group with over 1,500 consultants, we have the expertise and resources to tackle any technical challenge or business goal.

Rebel App Studio by Codemate is, above all, about our awesome employees, and our top priority is to give them opportunities to grow and advance in their careers. One of the best ways to grow is by collaborating with a team of experts who inspire and challenge you. This commitment is reflected in some key achievements from 2024:

🚀 Our eNPS remains consistently excellent, scoring above 50.
👩‍💻 The average coding experience across our team is now 15+ years.
🏆 The median employee tenure has reached an impressive 6.8 years.

Unlocking new platforms

This year, we are continuing to unlock Flutter’s full potential, exploring new possibilities with projects targeting emerging screens. As early adopters, we were among the first in the world to create a production Flutter app – Hookle’s iOS and Android apps launched in 2017 while Flutter was still in beta. In 2021, we broke new ground again with the Moi Web app, one of the first Flutter for Web applications. Now, in 2024, we are thrilled to announce that we are developing multiple Flutter apps for TV platforms, including Android TV, Tizen and webOS. 

Building solutions that make a difference

This year, our team was privileged to work on impactful projects that solve real-world problems.

Here are some highlights:

📰 Media Group Keskisuomalainen: Driving digital transformation for Finland’s largest media group
📱 Moi Mobile: Elevating a bold mobile operator contender to the next level
🌮 Taco Bell Finland: Creating a user-centric app to boost customer engagement

These collaborations showcase our ability to create innovative, tailored solutions that meet the unique needs of our clients and their users.

Sharing knowledge, building community

This year, our Rebels took centre stage on the global Flutter scene. In July, we joined Fluttercon Europe, sharing our expertise and connecting with the vibrant Flutter community. Not stopping there, we had the honour of participating in the first-ever Fluttercon USA in September.

For the second consecutive year, we partnered with Flutter & Friends to host engaging livestreams, further cementing our place in the Flutter ecosystem. These collaborations allowed us to share insights, learn from others, and contribute to the ever-growing Flutter ecosystem.

Building for everyone: Accessibility and localisation highlights of 2024

Empowering the Flutter community with practical, developer-friendly solutions is at the core of what we do. In fall 2024, we launched Rebellion, a tool designed to simplify localisation in Flutter apps. With Rebellion, developers can easily check localisation files for errors, making it easier to create apps that resonate with users worldwide.

Accessibility also saw major strides. We updated our Accessibility Tools, by adding a set of tools for manual accessibility testing. Now font size, dark/light theme, text direction, bold text flag, and visual density can be changed directly from the app to ensure that your app handles changes correctly. This aligns with our focus on the upcoming European Accessibility Act, which will bring accessibility requirements to new heights in 2025.

Psst 🤫 Our senior developer Alexander shared insights on accessibility tools during Fluttercon Europe—check out his talk here.

Looking forward

To date, we have released over 80 Flutter applications, solidifying our expertise and commitment to delivering exceptional cross-platform solutions.

As we prepare for 2025, we’re excited to continue innovating, collaborating, and growing within the Flutter community. Thank you to our clients, partners, and team members for making 2024 unforgettable. Here’s to an even brighter future!

Would you benefit from having extremely senior Flutter experts on your team?

In this blog, we summarise the insights from software developer, Joakim Liukkonen, who coded a simple app using both tools.

Key differences in resource usage

Why consider FlutterFlow? Here are some factors that standout:

⌚ Time savings

FlutterFlow’s drag-and-drop interface makes prototyping faster, saving valuable time for other essential project phases, such as gathering customer requirements and design.

💵 Cost efficiency

With faster production times, you can save money on development costs, especially during the early stages. FlutterFlow is also an excellent tool for less experienced developers or interns to contribute to simpler tasks, lowering overall resource costs.

⚖️ Lower expertise requirements

FlutterFlow is beginner-friendly and requires less expertise to get started, making it an ideal choice for teams with limited experience in mobile development.

While these factors make FlutterFlow appealing, Flutter has its advantages. Though it may take longer to develop prototypes, Flutter produces robust, cross-platform applications with code quality that stands out, especially when handled by experienced developers. If your project demands higher complexity and long-term maintenance, Flutter’s flexibility and powerful features are more likely to meet your needs.

Choosing between Flutter and FlutterFlow

When deciding between Flutter and FlutterFlow, consider the nature of your project. If you’re focusing on quick prototypes or proofs of concept, FlutterFlow’s speed and ease of use are highly advantageous. However, for larger, more intricate projects that require expert-level customisation and long-term code maintenance, Flutter is the better choice.

In some cases, you may find a complementary approach works best – using both tools where they excel. For instance, you can create a prototype in FlutterFlow but switch to Flutter for full-scale development, keeping in mind the limitations of back-and-forth transitions between the two.

A simple example elaborating the difference between Flutter and FlutterFlow code.

Developer experience: Flutter vs. FlutterFlow

The development experience with Flutter and FlutterFlow differs significantly based on a developer’s expertise level.

Flutter allows senior developers to take full control of the code structure, optimising it for maintainability and performance. Experienced developers prefer this freedom, as it enables them to produce clean, efficient code tailored to the project’s specific needs.

FlutterFlow drag and drop editor.

On the other hand, FlutterFlow’s drag-and-drop interface requires minimal coding skills, making it ideal for less experienced developers. However, as projects grow more complex, FlutterFlow’s auto-generated code can become difficult to manage, especially compared to the well-structured code that can be written with Flutter.

During our experiment, Liukkonen noted that FlutterFlow lacks the flexibility to organise widgets, variables, or files in a developer-friendly manner. In contrast, Flutter gives developers complete control over how they structure the app, allowing for greater scalability and easier code management.

Final takeaways: Which tool should you use?

Here are three key takeaways from our experiment:

🤙🏽 FlutterFlow excels in prototyping and quick PoCs

Its low barrier to entry allows for rapid prototyping, enabling more team members to contribute to the development process, even with minimal coding experience.

👥 Flutter is the go-to for complex projects requiring expert-level control

Projects that require a high degree of customization and long-term maintenance benefit from the flexibility and structure Flutter offers, making it the preferred tool for senior developers.

💙 Resource savings intrigue many companies

For short-term projects or those needing quick proof-of-concept development, FlutterFlow’s simplicity and speed make it an attractive option. It also enables non-developers to contribute to UI changes, speeding up updates and involving more team members in the process.

Bonus Tip:

FlutterFlow can even be a fun, easy way to introduce coding concepts to beginners – including primary school students! 🖥️

Widget tests

Widgets tests despite their name can help testing the whole user flow, not only separate widgets. For example, Burger King Suomi app has many widget tests to test that the most important parts of what the user does in the app work as expected: signing in, finding a restaurant, using coupons, customizing a meal, placing an order. Some tests check the whole flow end to end: from app launch to successfully placed order.

Since widgets tests can be run headlessly (without a device or emulator) it’s impossible to make network calls, use actual user accounts and real backend responses. In order to overcome this we’re using a lot of mock data.

Most of the mocks are happening at the very bottom of the app’s layered architecture. For example, HTTP client returns mock API responses in order to return a certain menu structure, coupon or error code. Mocking API calls makes the app work architecturally the same way it does when using actual API responses. These mocks don’t change the way app’s business logic works, there’s no special “test app behavior”.

The reason we’re using widgets tests to test user flows is that they’re easier to write and faster to run than Flutter’s integration tests. We run widget tests before every pull request can be merged to main.

Here’s an example of a simple widget test for ShoppingCardWidget’s functionality of adding cart items:

testWidgets(
  'ShoppingCartWidget can add items to the cart',
  (WidgetTester tester) async {
    // Build the widget
    await tester.pumpWidget(ShoppingCartWidget());
    await tester.pumpAndSettle();

    // Verify that the cart is initially empty
    expect(find.text('Cart is empty'), findsOneWidget);

    // Tap on the "Add Item" button
    await tester.tap(find.text('Add to cart'));
    await tester.pumpAndSettle();

    // Verify that the cart now contains the added item
    expect(find.text('Item added to cart'), findsOneWidget);
    expect(find.text('Cart: 1 item'), findsOneWidget);
  },
);

Golden tests

Running tests headlessly is the same as running the app on a device but instead of an app or a window for drawing it uses a virtual canvas. This canvas is an array of pixels and can be saved as a picture.

Golden tests compare the current state of the canvas with the previously saved state. In practice it works as pixel by pixel comparison of screenshots. In a way it’s the same old “expect” but instead of checking an object it compares two images.

As with other test types, it’s important to test what actually matters. Golden tests easily fail if there’s a tiny UI change. It’s easy to update golden files but it’s harder to validate these changes. For example, if there’s a one-liner color change in the app’s theme it’s quite possible that a lot of PNGs would need to be regenerated and thoroughly checked by a human at the pull request review step. This could lead to issues when reviewer didn’t notice some unwanted changes.

Here’s an addition to the previous code example where golden test is used to check how widget looks before and after new card item is added:

// Build the widget
// ...

// Initial state: cart is empty
await screenMatchesGolden(tester, 'shopping_cart_widget_initial');

// Tap on the "Add Item" button
// ...

// One cart item state
await screenMatchesGolden(tester, 'shopping_cart_widget_one_item');

Testing is an important part of the app development process. Deciding what and how to test is crucial for ensuring the reliability and functionality of the app. Framework and community offer many options for testing. To learn more about testing Flutter apps explore official documentation and golden_toolkit package documentation.

Wrap up

We hope you have enjoyed reading some of our thoughts on Flutter test automation and perhaps will take a few ideas that can promote active discussion before you jump in. Follow our Rebel App Studio X account if you haven’t already. We share timely topics and provide updates on Flutter related events we are arranging or participating in.

Flutter is our key technology used in RebelApps Studio; our flagship Flutter team that is part of Codemate. We are actively involved in core flutter expansion and development with Google.

Here we look at some of the tools available, the different layers and goals of each and share some of our thinking. Hopefully these are valuable to others. Especially for the developers and testers who are embarking on their first steps with the Flutter framework. It also a bit of a kudos shout out to the Flutter community in general, a key element for the continued ongoing success of Flutter as an often preferred framework.

Community Factor

One of the reasons the Flutter framework is thriving is the community of awesome people utilising it and contributing to improve it.

Community provides fantastic learning opportunities often from teams or individuals who are facing similar situations and challenges. So when we wanted to extend our use of test automation tools it was initially the community we looked to.

At some recent community meetups as Rebel App Studio we encountered LeanCode, they have been working on Patrol which extends the abilities of the inbuilt automation tools. LeanCode open sourced Patrol to community. We have it in active use so we will also touch on this in the article. 

Our test guild members have been contacted from the broader testing community looking to get started on Flutter automation. We’ve included a section “Tester Insight” that the community may also find useful. 

Kudos to the community.

Unit testing – Inbuilt Flutter tools

At unit level the goals are fairly common across most projects: develop quality software at optimal pace, rapid almost immediate feedback loop, verification that single functions or classes work in isolation.

Whilst not limited to unit tests there is also value in mocking any dependencies. This keeps the focus on the specific class you are testing and keeps the run speed optimal.

The Flutter documentation on both unit and widget test level is fairly good.

Widget testing

At widget level this shares the same optimal pace and rapid feedback loop goals but also adds in some basic verification that each widget looks and behaves as expected alongside some regression risk coverage goals.

The widgets can be run in isolation so it is not a requirement to build the entire app and you can run these tests without emulators or devices. You can gain insight at UI level whilst maintaining very rapid test runs.

Golden tests are another option here comparing the UI visually to catch regressions. Note that there is an indication that these can take longer to run so consider a balance between speed and value.

One value of adding Patrol finders is its optimised finder feature. It helps to create less and cleaner coder which in turn leads to lower development and maintenance costs. A significant value in our view. 

We were very early adopters of these tools at the above levels and we created these tests as we built the product. It will vary from project to project but generally we tend to have more coverage at the unit and widget levels than the end to end user flow layer.

Continuous Integration

In order to gain the full value of these tests, particularly the rapid feedback aspect, it makes sense for these to be run on every change as part of your CI implementation.

User end to end layer or Integration layer in Flutter terms

In the paired article we raised a couple of challenges at this layer and these factored into our general choice of value goals and the model that impacts the choice tools. We do evaluate and choose models and tools on a case by case basis.

The choice of in-built integration test tools is aligned with some of our values of close team collaboration. Our professional testers and developers often pair together and it allows the test automation code to remain fairly close to the product code base. Therefore we gain higher levels of efficiency.

The following is often a reasonable starting goal for this layer: provide a consistent health test level coverage of user core end to end flows. This offers value in terms of basic feature verification, some regression risk coverage, timely feedback loops, alongside a waste reduction readiness check for deeper investigation into those unknowns our testers love to explore.

Flutter inbuilt integration test layer

The Integration testing layer did meet our very basic needs. It was suitable for the creation of the straight forward health tests of key user flows within the apps. Like in many other frameworks we needed to add a lot of code to identify the widgets and elements we wanted to interact with. We do however regard it currently as still limited from a few aspects such as interaction with webviews outside the app or native device settings that could restrict any expansion beyond these basics.

Patrol – Open source UI testing framework

Patrol has hot restarts which provides significant time saving when developing your tests.

The next valuable area to us was the Native Automation features that Patrol introduced.  It’s a key feature that allows your tests to interact with the native side of things including notifications, webviews, permissions and device settings. By doing so you can broaden the coverage in your tests. Generally we found that it extends the Integration test tool and was fairly straightforward to start using it. It is ongoing development and we did run into a few challenges but overall the value seems good so far. At the time of writing a new version is recently out and there are some key improvements that we are following with interest and look forward to experimenting with. 

CI: End to end tests are slower to run than the other layers. You need to choose when to run these as part of your CI process. This is one of the reasons we often opt for light coverage at this layer. Patrol has sharding features that can help with speeding up your test runs but you may decide to schedule some of the tests to avoid slowing down the development.

Testers insight

This model encourages close collaboration and is a close to product code approach, it’s also a mobile application solution so it’s not as straightforward as pointing to web url and be scripting in an hour or so.

You will be using developer tools, building locally, reading product code, be comfortable doing low risk changes to product code like adding keys to widgets and also doing some actual code within your automation scripts. The level of your coding skills needed will vary but we recommend at least basic skills. Pair with a mobile developer at least initially if possible. In addition to the team collaboration and efficiency levels your understanding and communication levels with developers will also improve.

Automation is great, but when it comes to finding deeper, often more impactful issues and edge cases, hands-on risk based testing is very much needed. The aim should be to maintain a bigger picture holistic view of quality and testing. Testability of Flutter apps can get a bit complex. For example it’s not easy to see user traffic when your app gets delivered via Testflight or Appcenter. Utilising those developer focused tools and doing local builds will also be a valuable addition to your toolbox as you look to discover and investigate risks during your testing sessions. This provides a strong feedback loop into improving your automated coverage.

Wrap up

We hope you have enjoyed reading some of our thoughts on Flutter test automation and perhaps will take a few ideas that can promote active discussion before you jump in. Stay tuned for our next article that is even a deeper dive into Flutter test automation. And follow our Rebel App Studio X account if you haven’t already. We share timely topics and provide updates on Flutter related events we are arranging or participating in.

Here we will look at the early consideration of automation tools, and how these tools can be leveraged to enhance the achievement of your goals, advance your missions, and effectively tackle the challenges you seek to resolve.

It’s high level content aimed at the whole team, whilst it won’t provide you with specific solutions it will hopefully give your team some thoughts and ideas to discuss to empower good decisions with regards to automation.

Don’t jump in, just yet

Automation can at times get labeled with almost magical expectations that it is “the” go to solution for quality problems.

The reality is generally very different. Up front quality evaluations can often highlight both automation opportunities and flag other opportunities to improve things that may be better suited to the problem you are trying to solve. When it comes to product automation we suggest a few fundamental principles to consider before getting started.

Some of these may seem initially counterintuitive but they are based on a lot of real experience and projects in this field so please bear with us. We believe the concepts could be invaluable to our customers particularly when it comes to getting everyone’s expectations aligned.

Basic principles before we start

Your decision to leverage automation follows the same consideration as any other tool; what problem are you trying to solve, what are your goals and the expected value you want it to provide. 

With specific regards to test automation, if your primary goal is cost or effort savings it is an amber flag that you have other issues in your development or testing process. We can help you evaluate that risk.

Test automation scripts are really good for verifying known risks; test cases either pass or fail.

New products have far more unknown risks, even when automation is fully in place. It makes sense to maintain a holistic testing view that also includes other needed testing areas and development practices. Automation will not replace this good practice but is a necessary extension.

Potential goals of automation

Consider your automation goals in advance of any other decisions. Automation can be used in many areas of software development. The following list includes a few of those ideas even though we won’t dive into all the areas within this article.

These goals not only impact your decision to leverage automation but will also help with other factors such as who will automate, the level you automate at and what tools you will select to assist you.

Layers of automation

The consideration of layers is very important because it asks the question, “At what level is it most efficient to catch a specific type of issue should an issue of that kind exist?” The unit and api layers tend to have narrower goals;  to get the rapid feedback loop from test results to the team.  It has great value in daily development work as developers quickly learn how well the code works. Ideally these tests are quick to create and run but also easy to maintain. 

Some of the ideas behind the Automation pyramid align with these key attributes. The pyramid also indicates the track to find a root cause for a single feature error. One should start tracking root causes for errors from the lowest level of a pyramid and only then move upwards. We don’t recommend blindly following this model but it is potentially useful for considering if it’s a good match for your current project.

The pyramid is very specific to test automation and does not apply to your overall testing model.  For a much broader viewpoint in risk management the holistic approach  is recommended.

User facing end to end flows

The layer is the most complex layer to automate at, it has more dependencies, higher maintenance costs and a slower feedback loop than the lower levels. At this layer good development architecture practices are needed with automation, as are basic coding skills.

Mobile App automation can further complicate things compared to web apps, as there are less tools available and it’s often less testable. For example on a web application often it’s a straightforward case of directing a tool to a url, whereas on mobile apps you may need to consider things like emulators, debuggable builds, WebView’s outside of the application and native device configurations. It remains a very important opportunity for automation though particularly when it comes to the significant device variation risk. When it comes to the end to end layer and finding issues, hands-on risk based testing will often offer much more value.

Common automation models

Here are two example models we have leveraged from both where our own team is building the product and where our automation engineers step in to help out our customers teams.

Efficiency focused team model

This model really suits new products where close team collaboration is at the center of development. It’s designed to keep the automation code even at the end to end layer as close to the whole team and product code as possible.

The combination of high levels of collaboration, whole team contribution and building in parallel to product code make this a highly efficient approach to leveraging automation. 

It can be challenging initially for testers as some coding is required and we’ll often pair developers and testers together on automation to get the most out of this model. Our next article about Flutter automation will go into more detail on this approach.

Regression or complexity risk model. 

There are also many products/services out there which have run into regression issues and over time it has become detrimental to the team.  Automation can be used to primarily reveal the issues and to cover this risk.

It’s often worth optimising the efficiency of the Agile team model by utilising test automation so that it frees the developers from fighting regression risk fires on a daily basis.

In the hands of full time automation engineers the end to end coverage will often go broader and deeper. As it is distanced slightly from the developers and the code, there is the potential to utilise more tester friendly tools.

Once broad coverage of regression risk is in place it can be easier for the team to start addressing the root causes of the risk and consider a more optimal model going forward. 

Wrap up

We hope you have enjoyed reading some of our thoughts on automation and perhaps will take a few ideas that can promote active discussion before you jump in. It’s a great tool to add to your software development toolbox and help teams from many angles. We have a lot of experience in this area so get in touch for a chat and we can explore some options together. Or stay tuned for our next article that focuses on Flutter test automation. 

During the research, I got to learn about the collaboration between designers and developers by being part of an experienced and supportive team of Timo Pieti and Petri Pystynen while getting ready for the Fluttercon23 event. The team focused on finding ways to create multibranding with Figma and Flutter. Not only was Flutter a rather new topic, but design tokens were something I had not stumbled across before.

The team I entered explained to me what they were trying to achieve and what design tokens are. The research goal was to find an automated, low-cost, and low-configuration requiring process for the transformation of design tokens from Figma to Flutter. To accomplish this, the research consisted of three phases, a background study, testing, and analysis. Let’s go through them in brief.

Study

Getting ready for the Fluttercon23 event, the background study was the first thing on the agenda to gain understanding of design tokens. Design tokens are small repeated pieces of the design system that help the building of user interfaces creating consistency to the system (Chenais, 2018). Parameters that can be tokenized include colors, measurements, and fonts. A tokenized design system must be treated as the “single source of truth” to all design token solutions (Design Token Community Group). This helps the team by creating a synchroniced and up-to-date source for design tokens that everyone on the team can, and must, use. Design tokens also allow the creation of themes which can help with multibranding by easing the switching between different themes.

Testing

Testing the transformation of design tokens into Flutter code involved tools like Supernova.io, Tokens Studio, and Parabeac as well as many others. As design tokens are a rather new thing, many of the found design management tools didn’t support their usage, which resulted in only using Supernova and Tokens Studio in the final result.

Testing consisted of trying simple actions like creating the tokens, applying themes, or transforming created tokens into Flutter code. If any of those steps failed to meet the requirements of creating easy collaboration with developers and designers or needed too much manual work, the test ended in a failed attempt. All tests were analysed and learned from, to gain knowledge of the tokenized design system’s usage.

Key findings

A new workflow was created: New workflows for creating feasibility in the designer and developer collaboration on the design handoff phase were found as the result of the research. This included creating the tokens in Figma with Tokens Studio and using Supernova for managing and exporting the tokens into code. Supernova was integrated straight to the Tokens Studio for Figma plugin which allowed tokens to be easily moved into Supernova. From Supernova to Flutter, the export was done with the Flutter-exporter provided by Supernova. Overall, this workflow included some manual work in the mapping stage, occurring when moving tokens to Supernova, and when exporting multiple themes into code.

Importance of identical naming: Important aspect in token creation is the need for identical naming when creating multiple themes. Token naming takes time but with proper usage the themes can be easily integrated and exported into code which will save time and workload in the end.

Communication can be eased up: Developers and designers are known for not properly discussing and sharing their knowledge between the roles. That should be left in the past and they should start properly communicating. Design hand-off can be a crucial part of the software development process and information should be effortlessly shared. With the created workflow, it is provided that all design solutions are stored in one place and can be accessed by everyone in the team.

The more in depth steps for the transformation can be found in the Fluttercon GitHub repository linked below. The result of the automated process was not fully achieved, though we found a good enough workaround, with our developed workflow. Therefore, the transformation of design tokens is a good topic for future studies as well.

Dive deeper

If you want to learn more about the design tokens and collaborative ways to work with them you can check out the following material, including the talk and included material given at Fluttercon23.

Unlock Efficient Multibranding with Figma and Flutter

Fluttercon demo Github