Todo líder de produto que lançou em mais de uma plataforma conhece o imposto silencioso. A mesma tela de login, o mesmo checkout, a mesma página de configurações — escritas três vezes, em três linguagens, por três equipes que nunca terminam de coincidir. iOS em Swift. Android em Kotlin. Web em TypeScript. Uma função vira três orçamentos de engenharia, três filas de bugs e três trens de release que se afastam.
Vi equipes queimar suas melhores pessoas mantendo três implementações sincronizadas em vez de construir o próximo passo. A redundância não é um custo único. Ela se acumula.
A aritmética de três superfícies
O mercado móvel não te deixa escolher cobertura. O Android tem a grande maioria do share global fora da América do Norte; o iOS domina os segmentos de alto valor da América do Norte e do Japão; e um fallback web é a entrada para desktop e links compartilháveis. Os números do StatCounter colocam o Android acima de 70% do uso móvel global e o iOS nos altos dez por cento — você não serve o mercado com um só. Então você lota três stacks.
O custo aparece em três lugares. Primeiro, custo de build: a mesma lógica re-implementada três vezes, com bugs específicos por plataforma cada vez. Segundo, manutenção: um defeito corrigido no iOS ainda vive no Android e web até alguém notar. Terceiro, deriva: as três versões se bifurcam em comportamento em silêncio, então seu «um produto» se sente inconsistente para usuários que trocam de dispositivo.
Frente a frente
| Dimensão | iOS + Android + Web nativos | Runtime universal (um código) |
|---|---|---|
| Stacks de engenharia | Três (Swift, Kotlin, TS) | Um |
| Custo de build | Função × 3 | Função × 1 |
| Superfície de bug | Triplicada, por plataforma | Única, compartilhada |
| Cadência de release | Três trens, deriva | Uma pipeline |
| Alcance | Deve cobrir todas as plataformas | Corre em hosts/plataformas |
| Tamanho de equipe | Três especialistas | Uma equipe multiplataforma |
Um runtime universal muda a unidade de trabalho. Você escreve o serviço uma vez contra um runtime que provê identidade, pagamentos e componentes de UI de forma consistente em cada host e plataforma. As diferenças nativas — como um botão parece no iOS vs Android — são tratadas pelo adaptador de plataforma do runtime, não pela sua re-implementação. O modelo de catálogo aberto significa que o mesmo mini-programa corre dentro de muitas apps host sem que você o porte por host.
A ressalva honesta: um runtime não é esforço zero. As capacidades nativas de plataforma ainda precisam de mapeamento, e você troca a liberdade de três stacks sob medida pela restrição de uma superfície de API de runtime. Mas a troca converte um custo estrutural — tudo por triplicado — em um manejável. Para a maioria das equipes, essa é a diferencia entre lançar e não lançar.
Se você está lotando três equipes para dizer a mesma coisa de três formas, a pergunta não é «qual ferramenta cross-platform». É «por que estamos pagando para dizer três vezes».
