Flutter - The Framework Everyone Loves to Hate

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.

My take

I don't see Google dropping it, and it's not like Google does this out of the kindness of their hearths.

Cross-platform development serves Google's interests. Apple's App Store accounts for roughly 70% of consumer spending across the two big app stores. Without a cross-platform toolkit, a lot of developers and companies would pick iOS over Android.

Google even acknowledged this fact publicly: Flutter'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."

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 them 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 Facebook.

Here is a funny quote from Fireship about this fact: "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 adoption, 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

Another complaint is that Flutter code is ugly.

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

I definately agree with this complaint.

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.
Let's take iOS as an example. Because Flutter draws everything, it has to imitate everything that makes iOS feel like iOS:

• Navigation transitions
• Scroll physics, momentum, overscroll
• Typography
• Haptic feedback
• Back navigation
• Text editing and selection

But every time Apple or Google changes its design system (or other subtle things), Flutter has to catch up.

A good example of how this can go wrong was demonstrated last year, when Apple shipped iOS 26 with Liquid Glass in September 2025. A year later, Flutter still doesn't have it.

The Flutter team also realized this is a problem. That's why it 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 (aka dropped frames). I'll keep it short because the problem was 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. This approach caused performance issues, especially 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 iOS widgets are out of date.

Part of the problem is that Material Design is Flutter's default. Making an app look native on iOS takes a deliberate decision, so many developers don't bother — and ship Material Design everywhere. The result: lots of Flutter apps that look out of place on iOS, and people assuming that's the only kind of app Flutter can produce.

To visualize this I vibe coded the same app, once with Cupertino widgets and once with Material widgets:

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 to Flutter's approach: it throws away the native toolkits, then rebuilds them. To them, that's just wrong, and it's not something they can get past.

And I get it: from an engineering standpoint it's a giant 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 Seidel founded a company called Shorebird. Shorebird adds code push support to Flutter, and it's even mentioned in Flutter's FAQ. Shorebird is the de facto official solution for Code Push.

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:

• Library support
• Native integration
• Tooling
• The job market
• What your team already knows
• How many platforms you need

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.