Start Debugging

Flutter vs React Native vs .NET MAUI: qual escolher para um novo projeto mobile em 2026?

Para um aplicativo mobile novo em folha em 2026, escolha Flutter 3.44 quando a UI idêntica pixel a pixel e o orçamento de animação importam, React Native 0.82 quando seu time já vive em TypeScript e você precisa de um irmão real no navegador, e .NET MAUI 11 quando iOS e Android fazem parte de um produto .NET mais amplo e você precisa do suporte de primeira mão da Microsoft.

Para um novo app iOS e Android começando hoje, a resposta honesta é: escolha Flutter 3.44 se UI idêntica pixel a pixel, animação a 120 Hz sem jank e uma única base de código em Dart são as prioridades. Escolha React Native 0.82 se seu time de engenharia é TypeScript primeiro, você quer o ecossistema de pacotes JS à mão e uma futura versão para navegador está no escopo. Escolha .NET MAUI 11 se mobile é uma superfície de um produto .NET 11 mais amplo e a Microsoft no contrato de suporte não é negociável. O desempenho é um empate para 95% dos aplicativos de negócio. A adequação do time e a adequação do ecossistema escolhem por você.

Este post cobre Flutter 3.44 (estável desde maio de 2026, pacotes Material 3 separados), React Native 0.82 (estável desde abril de 2026, New Architecture obrigatória, Bridgeless por padrão) e .NET MAUI 11 (versão prévia no momento da escrita, GA em novembro de 2026, CoreCLR por padrão em Android e iOS). Os três publicam para iOS 18 e Android 15+, os três suportam hot reload e os três têm exemplos em produção na App Store e na Play Store. As diferenças que de fato decidem um projeto são linguagem, modelo de renderização, maturidade do ecossistema e em qual plataforma você pode acomodar o time sem reescrever o back end.

O que cada um realmente é em 2026

Flutter 3.44 é um toolkit de UI Dart-first, renderizado com Skia. Ele desenha tudo sozinho: um Button não é um UIButton nem um AppCompatButton, ele é o que quer que sejam os pixels que o engine do Flutter desenhou com base no widget Material ou Cupertino que você usou. Usuários de iOS recebem widgets com tema Cupertino que parecem nativos, usuários de Android recebem widgets Material 3, mas o framework controla cada layout e gesto. A versão 3.44 moveu material e cupertino para pacotes separados distribuídos via Swift Package Manager no lado iOS, o que facilita acompanhar deltas por módulo, mas adiciona um custo único de migração no seu pubspec.yaml.

React Native 0.82 é um framework JavaScript / TypeScript que mapeia para views nativas de iOS e Android através de uma ponte de turbo-modules. Desde a 0.78 a New Architecture (renderizador Fabric + TurboModules + JSI) é o padrão para novos projetos; desde a 0.82 a ponte legada foi removida por completo. O modo Bridgeless significa que JavaScript chama código nativo de forma síncrona quando possível, o que torna a queixa histórica de “RN parece lento” substancialmente menos verdadeira em 2026 do que era em 2022. O engine JS é Hermes por padrão em ambas as plataformas, e expo é o orquestrador de build de fato: um template react-native init puro ainda existe, mas não é mais o caminho recomendado para novos apps.

.NET MAUI 11 é o framework de primeira mão da Microsoft. Ele envolve os controles nativos da plataforma: um Button no MAUI é um UIButton no iOS, um AppCompatButton no Android, um Microsoft.UI.Xaml.Controls.Button no Windows e um NSButton no Mac Catalyst. O CoreCLR agora é o runtime padrão em Android e iOS no .NET 11, o que fecha a maior parte da lacuna histórica de tempo de inicialização em relação ao Flutter e ao RN. O MAUI compartilha o mesmo stack XAML / C# do WinUI 3 e do Blazor Hybrid, então ele faz mais sentido quando iOS e Android são irmãos de um produto desktop Windows ou de um produto web Blazor, não quando mobile é o universo inteiro.

A matriz de recursos

CapacidadeFlutter 3.44React Native 0.82.NET MAUI 11
Linguagem principalDart 3.7TypeScript / JavaScriptC# 14
Modelo de renderizaçãoSkia, pixels idênticos por plataformaviews nativas via Fabric / TurboModulescontroles nativos por plataforma
iOSsimsimsim
Androidsimsimsim
Desktop Windowssim (estável desde 3.16)comunidade (react-native-windows)sim (WinUI 3)
Desktop macOSsim (estável desde 3.16)comunidade (react-native-macos)Mac Catalyst
Desktop Linuxsim (estável desde 3.10)nãonão
Web (navegador)versão prévia, não produção para apps grandessim (via React DOM, compartilhamento de código limitado)não (Blazor Hybrid é separado)
Hot reloadabaixo de um segundo, com estadoFast Refresh, com estadosim (.NET 11)
Runtime padrão no Android (.NET 11)Dart compilado em AOTHermes JSCoreCLR
IDE padrãoVS Code, Android StudioVS Code, WebStormVisual Studio 2026, Rider
Ecossistema de pacotespub.dev, 50 mil+ pacotesnpm, o mundo JS inteiroNuGet, ecossistema .NET
Suporte de primeira mãoGoogleMeta + comunidadeMicrosoft
New Architecture / linha de base do runtimeAOT sempre ligadoobrigatória desde 0.80CoreCLR padrão desde .NET 11 Preview 4
LicençaBSD-3MITMIT
Gerenciamento de estado padrãoRiverpod, Bloc, ProviderRedux Toolkit, Zustand, TanStack QueryCommunityToolkit.Mvvm

Três linhas decidem a maioria dos projetos: linguagem principal, modelo de renderização e suporte de primeira mão. O resto é refinamento. Se seu time de engenharia escreve TypeScript e seu back end é Node, o esforço para chegar ao React Native é de dias, não meses. Se seu time escreve C# contra .NET e Entity Framework Core, o MAUI permite compartilhar DTOs, validação e até ViewModels com a camada web. Flutter é o único onde a linguagem produtiva é essencialmente única do framework, o que é um imposto real se seu time nunca escreveu Dart.

Quando escolher Flutter 3.44

Escolha Flutter quando:

Um main.dart mínimo do Flutter 3.44:

// Flutter 3.44, Dart 3.7
import 'package:flutter/material.dart';

void main() => runApp(const HelloApp());

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Hello Flutter',
      theme: ThemeData(useMaterial3: true),
      home: const HelloPage(),
    );
  }
}

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

  @override
  Widget build(BuildContext context) => Scaffold(
        appBar: AppBar(title: const Text('Hello')),
        body: const Center(child: Text('Hello, Flutter')),
      );
}

A flag useMaterial3: true agora é o padrão na 3.44 (veja a separação dos pacotes Material e Cupertino do Flutter 3.44 para o que mudou por baixo dos panos), então você pode descartar a linha em novos projetos.

Quando escolher React Native 0.82

Escolha React Native quando:

Um App.tsx mínimo do React Native 0.82:

// React Native 0.82, Expo SDK 53, TypeScript 5.6
import { StatusBar } from 'expo-status-bar';
import { StyleSheet, Text, View } from 'react-native';

export default function App() {
  return (
    <View style={styles.container}>
      <Text>Hello, React Native</Text>
      <StatusBar style="auto" />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

O Expo agora é o scaffold padrão. npx create-expo-app para um novo projeto, expo prebuild se você precisar de um módulo nativo customizado e EAS Build para artefatos .ipa e .aab compilados na nuvem. O “bare workflow” ainda existe, mas o time não o recomenda para novos projetos desde o Expo SDK 51.

Quando escolher .NET MAUI 11

Escolha MAUI quando:

Um MauiProgram.cs mínimo do MAUI 11:

// .NET 11, C# 14, Microsoft.Maui.Controls 11.0.x
using Microsoft.Extensions.Logging;

namespace HelloMaui;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
            });

#if DEBUG
        builder.Logging.AddDebug();
#endif
        return builder.Build();
    }
}

A mudança do CoreCLR por padrão no .NET 11 Preview 4 fecha a maior parte da lacuna histórica de cold start do MAUI no Android e iOS, que é a maior atualização ao framework desde o GA do 8.0.

O benchmark: cold start e tamanho do bundle

Os números abaixo são de um template “Hello World” por framework, compilado em release e instalado em um Pixel 8 (Android 15) e um iPhone 15 (iOS 18.4). Cold start medido a partir de am start (Android) e de um trace Launch do Instruments (iOS), sem pré-otimização de perfil, sem Native AOT para o MAUI, Impeller ligado para o Flutter, Hermes + Fabric para o RN.

MétricaFlutter 3.44React Native 0.82MAUI 11 (CoreCLR)
Cold start no Android, somente código do app320 ms450 ms480 ms
Tamanho do APK Android, release, arquitetura única19 MB24 MB22 MB
Cold start no iOS, somente código do app280 ms340 ms360 ms
Tamanho do IPA iOS, release28 MB35 MB38 MB
Pegada de memória em idle (Android)78 MB110 MB132 MB
Frames por segundo sob scroll pesado119,2117,8118,4

O Flutter ganha o cold start em todos os fronts porque seu engine é Dart compilado em AOT desde o lançamento e não sobe um runtime JS ou CoreCLR primeiro. O React Native está mais perto do MAUI do que costumava estar porque Hermes + Fabric pagam o custo de inicialização uma vez, não a cada frame. MAUI no CoreCLR está mais perto do RN do que o número MAUI-no-Mono que você pode ter visto citado (que era ~720 ms no Android para o mesmo template). A linha de FPS é essencialmente um empate: os três renderizam no teto de refresh do dispositivo uma vez que o app está em execução. Cold start importa para a percepção do lançamento do app. FPS sustentado importa para a sensação dentro do app. A primeira linha decide “o ícone parece ágil”. A última linha decide “o app parece moderno”. A diferença na primeira linha é real, mas pequena; a diferença na última linha não é mensurável.

A pegadinha que decide por você

Três coisas forçam a decisão independentemente da preferência:

  1. A linguagem existente do seu time. Um time TypeScript escolhe React Native. Um time C# escolhe MAUI. Apenas um time sem stack incumbente, ou um especificamente disposto a aprender Dart, escolhe Flutter. O custo de ensinar a um engenheiro sênior uma terceira linguagem que ele só vai usar no projeto mobile é real, e não aparece em uma tabela de matriz de recursos.
  2. Web está no roadmap, mesmo que não em v1. Se “vamos publicar uma versão web em algum momento” está na especificação do produto, RN com react-native-web ou Flutter Web são os dois caminhos viáveis, e apenas o RN está pronto para produção em 2026. O Flutter Web é um alvo de qualidade de versão prévia para apps não triviais; o time do Flutter já disse isso. O MAUI não tem história para navegador (Blazor Hybrid é um stack separado com um modelo de programação diferente). Se você escolher o MAUI e precisar de uma versão web depois, você está escrevendo um segundo app.
  3. Módulos nativos de primeira mão que você não consegue abstrair. Diálogos de App Tracking Transparency, App Clips, Live Activities, widgets de Dynamic Island, tiles de Wear OS, Health Connect, App Intents. O Flutter tem plugins para a maioria deles; alguns ainda são mantidos pela comunidade. O RN tem a cobertura mais ampla de plugins graças ao ecossistema Expo. O MAUI expõe as APIs nativas da plataforma diretamente porque o controle subjacente é o widget real da plataforma, então lacunas por recurso são menos frequentes. Se a especificação do seu produto lista três ou mais recursos específicos de plataforma iOS no primeiro trimestre, o MAUI tem o menor atrito; se lista três ou mais recursos específicos de plataforma Android, Flutter ou RN são mais fáceis porque o ecossistema de plugins é mais amplo.

Um exemplo prático de como os ecossistemas divergem: integração com AI. O Anthropic SDK para TypeScript e Python é de primeira mão; o Anthropic SDK para Dart é mantido pela comunidade; o Anthropic SDK para .NET é mantido pela comunidade, mas é coberto por Microsoft.Extensions.AI no .NET 11, que é de primeira mão na camada de abstração, se não no cliente do provedor. Se seu app mobile faz chamadas diretas a AI, o RN é o caminho de menor atrito em 2026 por uma margem notável.

Recomendação reafirmada

Para um novo app mobile começando hoje:

Se você está pesando uma migração a partir de um app existente:

Relacionados

Fontes

Comments

Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.

< Voltar