A slow animation, a not fluid scroll, or an unresponsive interaction that has a delayed response are some signals that tell that something is bad. It does not matter how good your app idea is; if the user experience is broken, your user’s perspective of the app is going to be a bad one, which will affect your app’s reputation from day one.

This article will construct a starting point to help us understand what it means for an app to have a good performance, I will tell you a couple of good practices I use when creating my own projects, and a tip or two on how we can user Flutter DevTools to debug performance issues in a Flutter application.

As a general Idea we should not get obsessed with premature optimization, but understand and learn to identify some performance bottlenecks so that we can take informed decisions over the app.

What does it mean to have good performance in a mobile application?

Let us start by discussing this question because it is not a trivial one. In a mobile application, good performance is not only about speed or the best hardware available on your device. From the user’s perspective, good performance is mainly about how the application feels while being used.

A performant mobile app feels smooth and responsive. Animations run without stutter, scrolling feels natural, and interactions respond immediately after a user taps the screen. End users rarely think in terms of milliseconds or frames per second; instead, they intuitively perceive when something feels slow, laggy, or unreliable.

In practical terms, good performance means that the application can deliver a consistent and fluid experience without blocking user interaction, even under non-ideal conditions such as older devices, limited memory, or background processes running at the same time.

Why is it important for our app to have good performance?

Performance has a direct impact on how users perceive an application.

Apps that feel slow or janky quickly generate frustration. This frustration translates into higher abandonment rates, poor reviews, and lower user retention. Even when an app’s functionality is correct, bad performance can make it feel unpolished or unstable, which erodes user trust.

From a product and business perspective, performance is not optional. It is part of the minimum quality bar. A performant app reduces friction, improves engagement, and allows users to focus on the value the app provides rather than on its technical limitations.

Android vs. iOS: Why performance context matters

When discussing mobile performance, platform context matters.

Generally speaking, iOS devices deliver better and more consistent performance than Android devices. This is largely because of Apple’s tightly controlled ecosystem and the close optimization between hardware and operating system. With fewer device variations, it is easier to maintain predictable performance across the platform.

Android, on the other hand, runs on a very wide range of devices with so many hardware capabilities. Entry-level and mid-range devices are common, especially in emerging markets, and performance constraints are much more visible in real-world usage.

This becomes clear when looking at benchmarks. For example, comparing an iPhone running iOS 13 against a Samsung A21s shows a significant gap in CPU, GPU, and memory power.

Market data reinforces this reality. In Latin America, roughly 80% of users are on Android. This means that for many applications, most users are running on devices where performance is not guaranteed by hardware alone.

If your primary audience is on Android, performance is not something you can postpone—it needs to be considered from the very beginning.

What is good performance in Flutter?

In Flutter, performance has a very concrete definition.

For a long time, a Flutter application was considered performant if it could consistently render at 60 frames per second (FPS), matching the refresh rate of most mobile displays.

In recent Flutter versions, the bar has been raised. Flutter now supports 120 FPS on devices with high refresh rate screens. This allows for much smoother animations and interactions, but it also reduces the margin for error.

In Flutter terms, good performance means consistently reaching the target frame rate of the device without dropping frames or introducing visible Jank.

Understanding the Flutter Rendering Pipeline

To understand how Flutter achieves high frame rates, we need to understand its Rendering Pipeline.

Each frame goes through several stages:

The UI thread, where widgets are built, layouts are calculated, and state changes are processed

The Raster thread, where the scene is converted into pixels

The GPU, which finally renders those pixels on the screen

To reach 120 FPS, every frame must complete in under ~8 milliseconds (1 second divided by 120). If any of these stages exceeds that time budget, frames are dropped, and the user perceives stutter or lag.

Therefore, many Flutter performance issues are related to blocking the UI thread or doing excessive rendering work.

Flutter performance best practices

To stay within the frame time budget, there are a few fundamental best practices that Flutter encourages:

• Avoid blocking the UI thread: Heavy or synchronous work on the UI thread will immediately result in dropped frames.

• Use Stateless widget whenever possible: Stateless widgets are cheaper to rebuild and easier for Flutter to optimize.

• Avoid rebuilding widgets unnecessarily: Rebuilding large portions of the widget tree when nothing meaningful has changed wastes valuable frame time.

• Avoid costly tasks Expensive computations: Heavy layouts, or very large widget trees can easily exceed the frame budget.

• Use Flutter DevTools: For performance monitoring DevTools make performance issues visible and measurable instead of relying on assumptions.

Common performance issues in Flutter

A very common performance issue appears when too numerous widgets are built at the same time. Large widget trees rendered all at once can overwhelm the UI thread, especially on lower-end Android devices. In Flutter DevTools, this usually appears as long frame times and frequent Jank.

Another frequent issue comes from unnecessary widget rebuilds caused by poor widget placement. A small widget that depends on frequently changing state can trigger a rebuild of its parent and all its descendants, even when most of the UI did not change. In DevTools, this shows up as repeated rebuilds of large parts of the widget tree.

These issues are not theoretical. They are extremely common in real Flutter applications and can be clearly identified using Flutter DevTools.

Conclusion

This only covers Flutter Performance in Flutter as an introduction. We can have a deeper dive into this topic in later articles. The only thing I want you to keep after reading this is that performance is not about premature micro-optimizations. It is about understanding the constraints of the rendering pipeline, the reality of user devices, and how our code interacts with both.

Flutter provides everything needed to build smooth, high-performance applications—even at 120 FPS. Achieving this consistently requires awareness, solid architectural decisions, and regular performance monitoring.

A better architecture — the one I actually use in my own projects — is:

Flutter → NestJS backend → Gemini API

This gives you security, observability, and full control of your AI layer.

In this article, I will walk you through the whole architecture and provide complete NestJS + Flutter code you can copy and use in your own apps.

Why You Should NOT Call Gemini Directly from Flutter

Before we start, you might be wondering why it's not a good idea to use the Gemini API key directly in your Flutter applications.

Calling Gemini (or any AI provider) straight from the mobile client creates several critical problems:

• Your API key will be exposed in case anyone reverse engineers your app.

• No rate limiting to protect your bill.

• No control over quotas, logs, or usage patterns.

• No way to enforce business rules (max prompt size, allowed features, etc.).

• You must ship new app versions if you want to change models or parameters.

Just to mention some reasons, this is why the correct architecture always includes a backend. NestJS sits between your Flutter app and Gemini, handling authentication, validation, logging, safeguards, rate limiting, and model management — while keeping your API keys 100% secure.

High-Level Architecture

NestJS becomes the “AI gateway” for all your apps — secure, flexible, and future-proof.

Before we start, please make sure you get a Gemini API key. You can get one from this page: https://aistudio.google.com/api-keys

Remember to create a Google Cloud Project before creating a new API Key.

1. Creating an AI Module in NestJS

Inside your NestJS project, we're gonna create a new module using NestJS CLI. On your terminal, put the following:

nest g module gemini

This will give us a new Module called Gemini.

src/gemini/gemini.module.ts
src/gemini/gemini.service.ts
src/gemini/gemini.controller.ts

NestJS CLI is a really cool tool that lets you create NestJS code really fast. This is one of the features I love most about Nest.

There are three key files: the Module, the Service, and the Controller. The Module acts as the orchestrator, wiring the controllers and providers for this Gemini Feature. The Gemini Controller communicates with the Gemini API through a use case that we will implement later on. And finally, the Gemini Service exposes the endpoints that our Flutter application will interact with.

gemini.module.ts

import { Module } from '@nestjs/common';
import { GeminiService } from './gemini.service';
import { GeminiController } from './gemini.controller';

@Module({
  controllers: [GeminiController],
  providers: [GeminiService],
})
export class GeminiModule {}

2. NestJS Service to Call Gemini

We're gona use @google/genai package. You can read the documentation in here for more information: https://ai.google.dev/gemini-api/docs For a better structure, we are gonna create a use case file as well. We have the following:

gemini.service.ts

import { Injectable } from '@nestjs/common';

import { GoogleGenAI } from '@google/genai';
import { geminiUseCase } from './use-cases/gemini.use-case';
import { GeminiPromptDto } from './dtos/gemini-promot.dto';

@Injectable()
export class GeminiService {
  private ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

  async geminiPrompt(geminiPromptDto: GeminiPromptDto) {
    return geminiUseCase(this.ai, geminiPromptDto);
  }
}

gemini.use-case.ts

import { GoogleGenAI } from '@google/genai';
import { GeminiPromptDto } from '../dtos/gemini-promot.dto';

export const geminiUseCase = async (
  ai: GoogleGenAI,
  basicPromptDto: GeminiPromptDto,
) => {
  const response = await ai.models.generateContent({
    model: 'gemini-2.5-flash',
    contents: basicPromptDto.prompt,
    config: {
      systemInstruction: `
      Responde únicamente en español
      En formato markdown
      Usa negritas de esta forma __
      Usa el sistema métrico decimal
      `,
    },
  });

  return response.text;
};

Add your key to .env :

GEMINI_API_KEY=your_key_here

3. Exposing a Clean Endpoint for Flutter

gemini.controller.ts

import { Body, Controller, Post } from '@nestjs/common';
import { GeminiService } from './gemini.service';
import { GeminiPromptDto } from './dtos/gemini-promot.dto';

@Controller('gemini')
export class GeminiController {
  constructor(private readonly geminiService: GeminiService) {}

  @Post('generate')
  basicPrompt(@Body() geminiPromptDto: GeminiPromptDto) {
    return this.geminiService.geminiPrompt(geminiPromptDto);
  }
}

Now you have:

POST /gemini/generate
{
  "prompt": "Write a product description for a tip calculator app."
}

4. Recommend Protections (Very Important in Production)

To operate AI safely:

Rate limiting:

import { Throttle } from '@nestjs/throttler';

@Throttle(5, 60) // 5 requests per minute

Validation Pipe

Prevent sending empty or malicious prompts.

API key or auth in your backend

Even a simple auth token adds a security layer.

Logging + token usage

Helps detect abuse and control monthly billing.

5. Calling NestJS from Flutter Using Dio

Here's a clean service class in Flutter:

ai_service.dart

import 'package:dio/dio.dart';

class AiService {
  final dio = Dio(BaseOptions(baseUrl: 'https://your-backend.com'));

  Future<String> generate(String prompt) async {
    try {
      final body = {'prompt': prompt};
      final response = await _dio.post('/gemini/generate', data: jsonEncode(body));
      return response.data;
    } catch (e) {
      return 'Error: $e';
    }
  }

6. Simple Flutter UI Example

chat_screen.dart

import 'package:flutter/material.dart';
import 'ai_service.dart';

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

  @override
  State<ChatScreen> createState() => _ChatScreenState();
}

class _ChatScreenState extends State<ChatScreen> {
  final controller = TextEditingController();
  final ai = AiService();
  String output = '';

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Gemini + Flutter')),
      body: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          children: [
            TextField(controller: controller),
            const SizedBox(height: 16),
            ElevatedButton(
              onPressed: () async {
                final text = await ai.generate(controller.text);
                setState(() {
                  output = text;
                });
              },
              child: const Text('Generate'),
            ),
            const SizedBox(height: 16),
            Text(output),
          ],
        ),
      ),
    );
  }
}

7. My Own Experience Using This Structure

In one of my recent projects, I'm following this exact architecture. It allows me to:

• Auto-generate text on a UI interface
• Detect objects in user-uploaded photos using Gemini Vision
• Generate suggestions, summaries, and metadata
• Run lightweight agents for business logic

Flutter’s role is simpler: it just sends some input, whether text or an image.

NestJS handles everything else — calling Gemini safely, cleaning the data, and returning structured results.

The app feels lighter and faster, and you don't worry about exposing keys or AI logic in the client.

8. Some Good Practices for Production AI

Here are a few things that can save you some headaches in production:

• Put a limit on how big prompts can be
• Cache common or repeated AI responses
• Track input/output tokens so you don’t get billing surprises
• Version your models as you upgrade (gemini-pro-1.5 → 2.0, etc.)
• Handle loading states properly — AI can take a moment
• Keep every model parameter and key on the server, never in the app

Conclusion

So there you have it. Using Flutter + NestJS + Gemini behind a backend isn’t just a “nice-to-have” architecture — it’s a solid, production-ready setup with real advantages:

• Your keys and logic never reach the mobile app
• You can change models or parameters instantly from your backend without deploying a new version of your app
• You control rate limits and usage because you have more control over your API usage
• One backend can power multiple apps or platforms

Thank you so much for reading this far, and let me know if you have any questions in the comment section.

Happy Coding. :D

Everything is a widget in Flutter, and we use widgets for everything from very easy components to very complex UI screens. However, developers commonly use method helpers for building UI components. I get it; I used to do it as well. They are easier to implement and, thus, faster to create complex UI elements. But we have to understand that this also comes with several downsides, especially performance issues.

In this article, I'm going to explain why using Method Helpers is not a good idea and why we should use Widget Classes instead.

Understanding Method Helpers and Widget Classes

Before diving into comparisons, I want all of us to be on the same page and explain what is a method helper in the context of Flutter.

So what's a Method Helper?

A method helper is a method that returns a widget, for example:

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('My Favorite Books'),
      ),
      body: Column(
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          _getItemOne(),
          _getItemTwo(),
        ],
      ),
    );
  }

  // This is a method helper
  Widget _getItemOne() {
    return const ListTile(
      title: Text('The Great Gatsby'),
      subtitle: Text('F. Scott Fitzgerald'),
      leading: Icon(Icons.book),
      trailing: Icon(Icons.favorite),
    );
  }

  // This is another method helper
  Widget _getItemTwo() {
    return Container(
      margin: const EdgeInsets.all(10),
      padding: const EdgeInsets.all(10),
      decoration: BoxDecoration(
        color: Colors.grey[200],
        borderRadius: BorderRadius.circular(10),
      ),
      child: const Column(
        children: [
          Text('The Catcher in the Rye'),
          Text('J.D. Salinger'),
        ],
      ),
    );
  }

If we refactor this code and create Widget classes instead, we can have the following:

class _FirstPageState extends State<FirstPage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('My Favorite Books'),
      ),
      body: const Column(
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          ItemOne(), // We have now a reference to a widget class
          ItemTwo(),
        ],
      ),
    );
  }
}

class ItemTwo extends StatelessWidget {
  const ItemTwo({
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    return Container(
      margin: const EdgeInsets.all(10),
      padding: const EdgeInsets.all(10),
      decoration: BoxDecoration(
        color: Colors.grey[200],
        borderRadius: BorderRadius.circular(10),
      ),
      child: const Column(
        children: [
          Text('The Catcher in the Rye'),
          Text('J.D. Salinger'),
        ],
      ),
    );
  }
}

class ItemOne extends StatelessWidget {
  const ItemOne({
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    return const ListTile(
      title: Text('The Great Gatsby'),
      subtitle: Text('F. Scott Fitzgerald'),
      leading: Icon(Icons.book),
      trailing: Icon(Icons.favorite),
    );
  }
}

We are writing a lot more code when creating Widget Classes. So, at first, using a method helper seemed more convenient because they are easier and faster to code, but there are some issues with Method Helpers:

Issues with method helpers

• Lack of reusability and Scalability: Method helpers are usually not reusable outside the widget they are defined in, limiting their utility when we need to reuse them in other UI components.

• Debugging and Testing Challenges: Debugging can also be more complicated because method helpers don't appear as a separe component in the widget tree, making them more difficult to be accesssed from a test.

• Poor Performance issues: So here's the catch: Widgets that are returned from methods do not maintain their state and are rebuilt every time the parent widget rebuilds. Why this can be troublesome?

Suppose we have the following widget:

import 'package:flutter/material.dart';

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

  @override
  State<FirstPage> createState() => _FirstPageState();
}

class _FirstPageState extends State<FirstPage> {
  bool switchValue = false;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('My Favorite Books'),
      ),
      body: Column(
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          _getBooks(),
        ],
      ),
    );
  }

  Widget _getItemList({
    required String bookName,
    required String authorName,
    required bool isFavorite,
  }) {
    return Padding(
      padding: const EdgeInsets.symmetric(horizontal: 15, vertical: 5),
      child: Card(
        child: ListTile(
          title: Text(bookName),
          subtitle: Text(authorName),
          trailing: IconButton(
            icon: Icon(isFavorite ? Icons.favorite : Icons.favorite_border),
            onPressed: () {},
          ),
        ),
      ),
    );
  }

  Widget _getBooks() {
    return Expanded(
      child: ListView(
        children: [
          _getItemList(
              bookName: "Ender's Game",
              authorName: "Orson Scott Card",
              isFavorite: true),
          _getItemList(
              bookName: "The Hitchhiker's Guide to the Galaxy",
              authorName: "Douglas Adams",
              isFavorite: false),
          _getItemList(
              bookName: "The Hobbit",
              authorName: "J. R. R. Tolkien",
              isFavorite: true),
          _getItemList(
              bookName: "Station Eleven",
              authorName: "Emily St. John Mandel",
              isFavorite: true),
          _getItemList(
              bookName: 'The Nightingale',
              authorName: 'Christin Hannah',
              isFavorite: true),
        ],
      ),
    );
  }

  Widget _toggleFavorite() {
    return Switch(
      value: switchValue,
      onChanged: (value) {
        setState(
          () {
            switchValue = value;
          },
        );
      },
    );
  }
}

I know it could be a more practical Widget, but bear with me. We have a Method Helper that is called toggleFavorite(); if you paid more attention, you could see the following:

  onChanged: (value) {
    setState(
      () {
        switchValue = value;
      },
    );
  },

That setState() method belongs to the parent Widget which we called FirstPage. Every time we're triggering this method, we are updating the closest Widget Class this Method Helper is implemented in, in this case the complete First Page widget, which contains some components that do not require to be updated. This can lead to performance issues in our Flutter application when we have a widget tree with multiple UI components.

If we refactor this code and use the following:

import 'package:flutter/material.dart';

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

  @override
  State<FirstPage> createState() => _FirstPageState();
}

class _FirstPageState extends State<FirstPage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('My Favorite Books'),
      ),
      body: const Column(
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          ToggleFavorite(), // <- Using the ToggleFavorite widget
        ],
      ),
    );
  }

}

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

  @override
  State<ToggleFavorite> createState() => _ToggleFavoriteState();
}

class _ToggleFavoriteState extends State<ToggleFavorite> {
  bool switchValue = false;

  @override
  Widget build(BuildContext context) {
    return Switch(
      value: switchValue,
      onChanged: (value) {
        setState(
          () {
            switchValue = value;
          },
        );
      },
    );
  }
}

Now the setState is isolated inside the ToggleFavorite Widget class that extends a Stateful Widget, updating only this isolated widget instead of the parent Widget, leading to a more performant application.

Now that we have a bit of a better understanding, we can list more benefits of using Widget Classes:

• Enhanced Reusability: By encapsulating our UI components, we have reuse them on different part of our applications.
• Easier Debugging and Testing: Since Widget Classes are isolated, create a Widget Test is also very easy as we only need the instance of the isolated widget and perform testing on it separately from other UI components.
• Improved Performance: Widget Classes mantain their state and context, which helps in optimizing the app performance overall.

Conclusion

So there you have it: performance issues are the main reason why we should avoid using Method Helpers. I understand that we are constantly under time pressure as developers and fall into doing what can be done faster. But by doing so, we can get ourselves into a more problematic situation that will be harder to solve if we keep doing this practice as the project grows. So remember always to use Widget Classes in order to create more performant applications. Thank you so much for reading this far, and let me know if you have any questions in the comment section.

Happy Coding. :D