Executando verificação de segurança...
2
adonaipinheiro
4 min de leitura ·

Por que sua próxima feature deveria começar com uma POC nativa antes de ir para Flutter ou React Native

Na semana passada, o Google liberou o Android Studio Hedgehog com melhorias significativas no profiler de memória e no Jetpack Compose preview. Já a Apple publicou uma nova série de vídeos sobre SwiftData mostrando como persistir dados de forma moderna. Ambos os anúncios têm algo em comum: o foco está cada vez mais nas plataformas nativas.

Isso pode parecer contraditório quando o mercado fala tanto em "escrever uma vez, rodar em todas as plataformas". Mas aqui vai uma perspectiva prática: antes de comprometer seu roadmap com Flutter ou React Native, vale a pena validar o conceito nativamente. Vou explicar por quê e como fazer isso sem perder velocidade.

O dilema do "cross-platform first"

Imagine que você precisa implementar uma funcionalidade que usa câmera, machine learning on-device e sincronização em tempo real. A tentação é grande de abrir o VS Code e criar um projeto Flutter, porque "vai rodar em iOS e Android". Mas eis o que geralmente acontece:

  • Semana 1: Setup inicial, tudo lindo
  • Semana 2: Descobre que a biblioteca de ML tem limitações em uma plataforma
  • Semana 3: Precisa escrever código nativo para ambos os lados
  • Semana 4: Está debugando issues de performance que não existiriam nativamente

O custo de oportunidade aqui é enorme. Enquanto isso, seu concorrente já lançou uma versão nativa que funciona perfeitamente em pelo menos uma plataforma.

O poder de uma POC nativa de 48 horas

Vamos ao que interessa: como validar rapidamente sem se perder em complexidade. Aqui está uma abordagem que uso há anos:

1. Defina o "core" da sua feature em uma frase

Exemplo: "Capturar imagem da câmera, processar texto OCR localmente e armazenar em cache offline"

2. Crie um projeto nativo mínimo

Android (Kotlin):

// build.gradle (Module: app)
dependencies {
    implementation 'androidx.camera:camera-camera2:1.3.0'
    implementation 'com.google.mlkit:text-recognition:16.0.0'
    implementation 'androidx.room:room-runtime:2.6.0'
}

iOS (Swift):

// ContentView.swift
import SwiftUI
import Vision
import VisionKit

struct ContentView: View {
    @State private var scanResult: String = ""
    
    var body: some View {
        VStack {
            Text(scanResult)
            DataScannerView(result: $scanResult)
        }
    }
}

3. Meça o que importa

Nesta fase, não estamos preocupados com código bonito. Estamos coletando dados:

  • Performance real: Quantos ms para processar uma imagem 4K?
  • Bateria: Quanto consome uma sessão de 100 fotos?
  • UX nativa: O usuário consegue navegar com gestos familiares?
  • Limitações reais: O que realmente NÃO é possível fazer?

A regra dos 70%

Aqui está uma métrica que desenvolvi ao longo do tempo: se 70% do seu tempo está sendo gasto em "plumbing" (configuração, adaptadores, bridges), é hora de reconsiderar.

Exemplo prático: Você está no Flutter e precisa acessar um sensor específico do Android que não tem plugin. Se:

  • 30% do tempo: Lógica de negócio
  • 70% do tempo: Escrevendo MethodChannel, testando, lidando com versionamento

Pare e vá nativo. A feature sairá mais rápido.

Checklist para decisão rápida

Antes de começar qualquer feature mobile, responda:

  1. Qual é o diferencial técnico? (câmera 60fps, ML complexa, integração com hardware)
  2. Qual plataforma tem mais usuários? (muitas vezes 80% está em uma)
  3. Qual é o prazo real? (atenção: não o prazo que o PO quer)
  4. Quem mantém? (time nativo vs. time cross-platform)

Se suas respostas indicarem complexidade técnica ou restrições de hardware, faça a POC nativa primeiro. Você pode até descobrir que a versão Android atende 90% dos usuários e a versão iOS pode esperar 2 semanas.

O futuro é híbrido (mas não como você pensa)

A verdade é que o futuro não é "100% Flutter" ou "100% nativo". É escolher a ferramenta certa para o problema. As grandes empresas já fazem isso:

  • Instagram: Navegação principal em React Native, câmera é nativa
  • Airbnb: Migrou para nativo justamente por questões de performance
  • Nubank: Misto calculado, cada feature é avaliada individualmente

Próximo passo

Na próxima vez que chegar uma demanda complexa, experimente:

  1. Dia 1: POC nativa na plataforma com mais usuários
  2. Dia 2: Colete métricas e tome decisão
  3. Dia 3: Só então decida se vai cross-platform ou mantém nativo

Esse processo de 3 dias pode economizar 3 semanas no futuro. E no mundo mobile, 3 semanas é a diferença entre liderar o mercado ou ser mais um app na loja.

O Android Studio Hedgehog e as novas APIs do iOS 17 só reforçam: as plataformas nativas estão mais maduras e produtivas do que nunca. Às vezes, a resposta mais moderna é justamente a mais tradicional.

Qual foi a última feature que você implementou cross-platform e acabou descobrindo que nativo seria mais simples? Compartilha aí nos comentários.

Carregando publicação patrocinada...