--- title: "O mercado está voltando ao nativo. O seu app nunca precisou" description: "Nativo ou cross-platform em 2026: por que o mercado volta a Swift e Kotlin, por que os apps GoodBarber sempre foram nativos e o que verificar antes de escolher." canonical_url: "https://pt.goodbarber.com/blog/o-mercado-esta-voltando-ao-nativo-o-seu-app-nunca-precisou-a1346/" lang: pt date: 2026-09-11 last_updated: 2026-09-15 --- # O mercado está voltando ao nativo. O seu app nunca precisou [Voltar](/blog/make-it-r19/) # O mercado está voltando ao nativo. O seu app nunca precisou Escrito por [Mathieu Poli](https://pt.goodbarber.com/blog/author/mathieu-poli/) na Sexta-Feira 11 Setembro 2026· Última atualização: Terça-Feira 15 Setembro 2026 ## Neste mês, a Shopify anunciou que todos os seus apps móveis estão voltando para Swift e Kotlin, seis anos depois de adotar o React Native. O mercado chama isso de volta ao nativo. Os apps GoodBarber nunca saíram de lá: apostamos no nativo em 2011, quando a maior parte do setor apostava o contrário. Veja o que essa aposta significa para o seu app, quanto custa, do que ela protege você e o que verificar antes de escolher um app builder. ## Nativo ou cross-platform: o que as palavras realmente significam ![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97995342-68228855.jpg?v=1789130563.1367035) Um app iOS criado com o GoodBarber é compilado em Swift. Um app Android é compilado em Kotlin. São as linguagens que a Apple e o Google usam nos próprios apps, e o resultado é um verdadeiro [app nativo](https://pt.goodbarber.com/glossary/native-app/): um binário que você envia à App Store e ao Google Play, exatamente como faria uma agência de desenvolvimento. Um terceiro motor produz uma Progressive Web App para o navegador e o computador. Os três são gerados a partir do mesmo back-office: você desenha o seu app uma vez, e cada motor o renderiza corretamente para a sua plataforma. Os detalhes dessa tecnologia estão na nossa página de [tecnologia nativa](https://pt.goodbarber.com/native/technology/). Os frameworks cross-platform, como React Native ou Flutter, seguem outro caminho: um único código compartilhado, exibido nas duas plataformas por meio de uma camada intermediária. É uma abordagem legítima, e durante anos foi a mais pragmática para uma empresa que constrói um único app. Também é a que escolhemos não seguir. ## Por que apostamos no nativo em 2011 Quando construímos os nossos primeiros motores, a pergunta não era qual tecnologia produzia o melhor app naquele ano. Era qual camada ainda existiria dali a dez anos. As plataformas existiriam: a Apple e o Google não iam abandonar os seus sistemas, as suas ferramentas, os seus SDKs. Tudo o que ficava no meio, os frameworks que prometiam poupar as plataformas aos desenvolvedores, ainda precisava conquistar a sua década de existência. Então construímos diretamente sobre a camada que com certeza permaneceria, e tratamos como temporário tudo o que se empilhava por cima. Os anos seguintes puseram essa leitura à prova. A cada poucos anos, um novo framework era apresentado como o futuro do mobile: PhoneGap, React Native, Xamarin, Flutter. Avaliamos os mais sérios e passamos a vez todas as vezes, pela mesma questão de longevidade. Depois vieram as respostas: [a Adobe descontinuou o PhoneGap em 2020](https://cordova.apache.org/announcements/2020/08/14/goodbye-phonegap.html), [a Microsoft encerrou o suporte ao Xamarin em 2024](https://dotnet.microsoft.com/en-us/platform/support/policy/xamarin). A camada intermediária não parou de mudar de nome. iOS e Android mantiveram o deles. A aposta tem um preço. Três motores são três equipes, três especialidades e três implementações para manter no mesmo ritmo, e é exatamente por isso que a maioria das empresas que constroem um único app não podia bancar isso. Uma plataforma pode: os motores são construídos uma vez e amortizados em cada app que ela produz. Quinze anos de criação de apps nativos se apoiam nessa aritmética, e é também por isso que esse custo nunca chega até você. Os motores, a hospedagem, a infraestrutura de notificações push e a publicação nas lojas estão incluídos na assinatura. ## O que isso muda para o seu app O seu app se apoia na fundação que a Apple e o Google mantêm eles mesmos, não em uma camada cujo futuro depende do roadmap de uma terceira empresa. Quando um framework é abandonado, nada acontece com o seu app. Quando o iOS ou o Android evoluem, os nossos motores adotam a mudança uma vez, de forma centralizada, e o seu app é regenerado na nova versão sem que você toque em nada. Um app configurado anos atrás é um app atualizado hoje. Isso também aparece no que os seus usuários sentem, abaixo do que a maioria das pessoas sabe nomear: uma rolagem que segue a física exata do sistema, transições que pertencem ao sistema operacional, resposta háptica, uma barra de abas flutuante, um player de mídia que continua tocando quando a tela apaga, notificações locais disparadas pelo próprio app quando alguém entra em uma área geográfica, sem nenhum servidor. Nada disso se configura. Vem com a forma como o app é construído, e os seus usuários resumem em uma palavra: "profissional". ## Por que isso importa mais em 2026 Algo mudou neste ano na forma como as equipes técnicas falam de mobile. Em setembro de 2026, [a Shopify anunciou](https://shopify.engineering/back-to-native) a volta de todos os seus apps móveis para Swift e Kotlin, seis anos depois de adotar o React Native, e o motivo não é que o nativo tenha melhorado de repente. É que a IA eliminou a principal razão para evitá-lo: o custo de construir o mesmo app duas vezes. Quando modelos e agentes cuidam da maior parte da tradução e dos testes entre plataformas, o código compartilhado perde o seu argumento econômico, e a linguagem própria de cada plataforma volta a ser a escolha padrão. Nós nunca precisamos fazer essa viagem, e a aposta se pagou de um jeito que não tínhamos previsto: contávamos com o tempo para provar, e a prova veio da IA. O nosso Head of Frontend Engineering, Mathieu Poli, conta essa história por dentro, incluindo os frameworks que avaliamos pelo caminho: [Everyone is going back to native. We never left](https://dev.to/goodbarber/everyone-is-going-back-to-native-we-never-left-and-the-bet-paid-in-a-way-we-didnt-expect-58lp). ## O que verificar ao escolher um app builder nativo Faça uma única pergunta: o que a plataforma realmente produz? Um binário Swift compilado e um binário Kotlin compilado, enviados às duas lojas em seu nome, são um objeto diferente de um app web empacotado para o celular. Peça para ver um app rodando em um telefone de verdade, e preste atenção à rolagem, às transições e à barra de abas. Se a resposta for nativa, você vai sentir antes que alguém explique. Você pode testar por conta própria: [comece um teste gratuito](https://pt.goodbarber.com/create/templates/), construa uma primeira versão do seu app e instale no seu telefone. ## FAQ **Os apps GoodBarber são realmente nativos?** Sim. O app iOS é compilado em Swift e o app Android em Kotlin, e os dois são enviados à App Store e ao Google Play como binários reais, em seu nome. O terceiro motor, a Progressive Web App, roda no navegador, e isso é intencional. **App nativo ou PWA, qual escolher?** Os dois saem do mesmo projeto GoodBarber, então raramente é um ou outro; [como escolher entre um site, um app e uma PWA](https://pt.goodbarber.com/blog/precisa-de-um-site-de-uma-app-ou-dos-dois-a-sua-pwa-e-discretamente-os-dois-a1318/) tem um artigo próprio. Os apps nativos são os que os seus usuários encontram nas lojas e os que dão a você a rolagem, as transições e os recursos do aparelho próprios de cada plataforma; a PWA acrescenta o navegador e o computador. **Um app nativo custa mais caro?** Não com um app builder. Os motores são construídos uma vez e amortizados em todos os apps da plataforma, de modo que o seu custo, junto com hospedagem, infraestrutura push e publicação nas lojas, está incluído na assinatura. O preço de construir duas vezes só se aplica ao desenvolvimento sob medida, e é a razão pela qual o mercado foi buscar alternativas. ![Mathieu Poli](https://blog.goodbarber.com/_public/profile/65/6553d00ecdbe15f8aac2da7dddcff47648fdd791-default.jpg) Sobre o autor[Mathieu Poli](https://pt.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering Sou Head of Frontend Engineering na GoodBarber Supervisiono as equipas que concebem os motores de renderização no coração da nossa plataforma no-code: são elas que dão vida aos projetos dos nossos utilizadores e os transformam em aplicações nativas, fluidas e cuidadas. Tudo o que se vê e se manipula no ecrã passa pelas suas mãos. Pioneiro do no-code móvel, apaixonado por arquitetura de software e design de produto, também dou aulas em universidades e escolas privadas. Aqui escrevo sobre engenharia frontend, design de produto e IA — e sobre tudo o que acontece quando estes três mundos se encontram. [Saiba mais](https://pt.goodbarber.com/blog/author/mathieu-poli/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/hellomathieup)[![X](https://portal.ww-cdn.com/portal_static/svg/base2021/x.820492c586dd.svg)](https://x.com/hellomathieup/)