Flutter - The Framework Everyone Loves to Hate

· 10 min read

On social media, opinions on Flutter are usually extreme: either it’s the best thing since sliced bread or it’s the worst framework ever.

Theo, a popular software development YouTuber, put it bluntly:

“I like to think it’s apparent once you’ve built a Flutter app, especially on iOS, that it’s a crap framework for building crap applications.”

It’s fair to say not everyone is a fan.

I’ve spent three years on a production Flutter app, one codebase shipped to iOS, Android and the web. I’m not here to defend Flutter. But I think Flutter deserves a more balanced view.

That’s why I wanted to look at the top five complaints that people seem to have with Flutter and find out which ones I actually agree with.

One disclaimer: I will refer to React Native several times. It is simply impossible to talk about Flutter without also mentioning React Native. But this is not a React Native vs. Flutter post. There are already plenty of those.

Below are the top five complaints that come up again and again, ranked from least to most common.

5. Google

The complaint

Some developers are hesitant to bet on Flutter because it is maintained by Google, and Google has a history of killing projects.

The point is fair. In my opinion, Flutter would not survive if Google were to abandon it, so the dependency is real.

In October 2024 a former Flutter engineer forked Flutter as Flock, arguing that the Flutter team, which he guessed at about 50 people, couldn’t keep up with the backlog. The fork struggled to attract contributors: of the 40 people who said they would contribute, one did.

A fork competing with a maintained upstream is not the same as an abandoned project. But if Google were to drop Flutter, the community would have a hard time keeping it alive.

My take

I don’t see Google dropping it.

Cross-platform development serves Google’s interests. The App Store takes well over half of consumer app spending. Without a cross-platform toolkit, a developer who is chasing revenue and can only afford one platform picks iOS. Flutter is how Google keeps Android in the same build.

Google says as much. The Flutter team’s public strategy document from 2023 says Flutter helps Android by “giving iOS developers a path to build on a supported Google stack that also targets Android.”

Google doesn’t publish the team’s size, and 50 is probably low. Former Flutter tech lead Ian Hickson counted 98 regular contributors among roughly 280 people with commit access in May 2024, and estimated that “about 85% are Googlers or somehow get their funding from Google.” That still leaves out people at Google who work on Flutter without committing code.

Whether the team is 50 people or a few hundred, it’s nothing to Google. Killing Flutter would save pocket change and cost a lot of trust, not to mention that it would go against Google’s own interests.

Besides, React Native has the same “issue” with Meta.

Fireship put it best: “React Native comes from Facebook, which has been criticized as being an evil tech corporation, while Flutter comes from Google, which has been criticized for being an evil tech corporation.”

You need a big tech company behind a cross-platform SDK. Flutter just happens to have Google.

4. Dart

The complaint

When Flutter arrived in 2017, React was already popular among web developers.

So one question came up early: why not just use JavaScript? Why Dart, instead of a language developers already knew?

Contrast this with React Native, which launched two years earlier and used JavaScript. It allowed web developers to ship a mobile app without picking up a new language or framework.

The Flutter team actually tried JavaScript first, but startup times got out of hand as the framework grew, so they moved to Dart, a language they could co-evolve with.

But picking an unknown language over a known one gave developers an easy reason to dismiss Flutter. I would argue that the decision to use Dart instead of another well-known programming language really hurt Flutter’s reputation, even in the long run.

My take

Is Dart the greatest language ever created? No, but it’s totally fine. If you know Java, TypeScript or C#, you’ll be able to learn it quickly.

The real issue is that most developers stick to one language and pick their frameworks from there. I don’t blame them. A new language is a hard sell when the one you know already gets the job done.

LLMs changed that calculation. Nowadays you can be productive from day one and pick up the details as you go.

3. The Ugly Duckling

The complaint

Flutter code is ugly. There. I said it.

Here are two simple counters.

React Native (Counter.jsx)

import { useState } from "react";
import { Button, Text, View } from "react-native";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <View>
      <Text>Count: {count}</Text>
      <Button title="Add" onPress={() => setCount(count + 1)} />
    </View>
  );
}

Flutter (counter_page.dart)

import 'package:flutter/material.dart';

class CounterPage extends StatefulWidget {
  const CounterPage({super.key});

  @override
  State<CounterPage> createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int _count = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Count: $_count'),
        ElevatedButton(
          onPressed: () => setState(() => _count++),
          child: const Text('Add'),
        ),
      ],
    );
  }
}

Compare them and one thing stands out: one is ugly, the other isn’t.

Flutter needs two classes and twice as much code.

One reason for this is that the Flutter team chose not to build a markup language. The FAQ argues that defining UI in code gives you hot reload, loops, conditionals and type safety. JSX has all of that too. I don’t follow the reasoning.

A 2024 proposal called Cutting the stateful boilerplate starts from the same observation: “Implementing a stateful widget in Flutter requires developers to write two classes.” It depended on Dart macros, and in January 2025 the Dart team stopped work on macros.

My take

Small widgets are fine. Large ones turn into a pyramid of nested constructors.

I wish I could say you get used to it.

I never did.

2. Native vs. Non-Native

The complaint

Flutter doesn’t use the UI components iOS and Android provide. Instead, it draws everything itself.

Most complaints about Flutter trace back to this one fact.

The criticism isn’t only about looks. Because Flutter draws everything, it has to imitate everything that makes iOS feel like iOS:

The imitation is good. Flutter matches scroll physics, transitions and text selection to whichever platform it runs on.

But every time Apple or Google changes its design system, Flutter has to catch up.

Apple shipped iOS 26 with Liquid Glass in September 2025. A year later, Flutter still doesn’t have it.

The Flutter team plans to split the widgets out of the main framework so new designs can ship faster.

Besides the visual and “feel” issues, this section would be incomplete without mentioning Flutter’s shader jank. I’ll keep it short, because the problem was largely solved on mobile when Flutter moved from Skia to Impeller.

So here is the TL;DR version:

Flutter loads → shaders compile at runtime → jank

The slightly longer version: for its first six years Flutter rendered with Skia, which compiled shaders at runtime. The first time an animation or shape appeared, the frame dropped. Users saw this as jank, usually right after app start.

The fix was a new rendering engine, Impeller, which precompiles shaders. It became the default on iOS in 2023 and on Android in 2024.

My take

If your app has to look and feel like Apple built it, don’t use Flutter.

But that’s less of a problem than it sounds. Most apps use their own design system anyway, so for them it simply doesn’t matter if Flutter’s imitation iOS widgets are out of date.

In my opinion, this complaint comes from developers who just use the default Material Design (from Android) and ship their app on iOS. In that case, it’s obvious that the app won’t look like it “belongs” on iOS.

Part of the problem is that Material Design is the default on Flutter, so if a developer wants a truly native-looking app on iOS, they have to make a conscious effort.

Here is the same app, once with Cupertino widgets and once with Material widgets:

The same habit tracker app side by side: Cupertino widgets on an iPhone simulator and Material widgets on an Android emulator

They look pretty different to me.

The other complaint is that Flutter apps don’t “feel” native.

“It doesn’t feel native” is hard to argue with because it’s hard to pin down. Nobody can fix a feeling. But when someone names the actual difference, like the way a list bounces when you overscroll, it can be fixed.

To me, Flutter’s rendering is a feature, not a bug. Because it paints every pixel itself, you can build a custom UI that looks identical on every platform.

Beyond these practical issues, some developers have a philosophical objection. Flutter throws away the native toolkits, then rebuilds them. To them, that’s just wrong.

And I get it: from an engineering standpoint it’s a huge task. But it’s a task I, as a user of the framework, don’t have to deal with.

1. Code Push

The complaint

Flutter does not support code push (aka over-the-air updates) out of the box. That means every update has to go through the approval process of the Apple App Store and the Play Store.

This also means that the modern development philosophy of continuous deployment (where production deployments can happen multiple times per day) is not possible out of the box with Flutter on iOS and Android.

Missing code push is by far the biggest complaint developers have about Flutter. This is obvious if you look at this GitHub issue, which is the most upvoted issue in the entire repository.

React Native developers have had code push for years, which is why Flutter developers want it so badly.

Even one of Flutter’s creators agrees. Eric Seidel opened that issue himself in 2018, while still on the Flutter team. After leaving Google, he wrote: “We started with Code Push, to address the #1 most up-voted issue on Flutter.”

The company Seidel founded is called Shorebird, and it’s even mentioned in Flutter’s FAQ. Shorebird is a separate company, but with one of Flutter’s creators behind it and a mention in the official docs, it is the de facto official solution.

My take

Shipping a fix in minutes instead of waiting on app review is a killer feature.

For many businesses this alone decides between Flutter and React Native, and I don’t blame them. But in Flutter’s defense, this feature is not available on the native platforms either, so clearly people are surviving without it.

Still, it is a downside of Flutter compared to React Native. Yes, Shorebird exists, but a third-party add-on is not the same as built-in code push.

So Is the Hate Deserved?

This list is not complete, of course. I could have made it a top 10, but I didn’t want to write a whole bible.

Evaluating a framework is more nuanced than most people realize, and there are plenty of topics I didn’t cover at all, such as:

Tech culture has a long memory. Most of the criticism I covered here was fair once, and some of it still is. But a reputation updates more slowly than a framework, and Flutter is a good example of this.

Of the five complaints, only one still holds up: code push. The rest are either outdated, overblown or a matter of taste.

So no, I don’t think the hate is deserved. Flutter is not perfect, but it’s a lot better than its reputation.

AI Disclosure

I used AI (Claude) to fix my embarrassingly numerous spelling and grammar mistakes.