Tem um pedaço do hype de IA que faz a discussão sobre mobile parecer torta. A conversa costuma girar em torno de uma pergunta dramática demais: a IA vai acabar com o desenvolvimento de apps?
O caso aberto que mais valeu ler hoje puxou a conversa para outro lugar — e esse lugar é bem mais útil.
No Ask HN sobre o estado do app development em 2026, um desenvolvedor contou que conseguiu montar um app de ditado para Mac e iOS com ajuda pesada de Claude e ficou impressionado com a velocidade. Mas, logo depois, veio a frase que muda a leitura inteira: “By far the worst (and slowest) part of the process is having to deal with the App Store”.
Esse detalhe importa mais do que parece. Porque ele separa duas coisas que muita gente ainda mistura: ficou mais fácil gerar código; não ficou automaticamente mais fácil publicar um app confiável, aprovado e encontrável.
O caso da comunidade não fala só de código
A thread do Hacker News é interessante justamente porque ela não ficou presa no clichê do “agora qualquer um vira dev”. O que apareceu ali foi um retrato mais honesto do mercado:
- o MVP ficou mais barato para muita gente;
- o app simples corre mais risco de virar commodity;
- review, metadata, distribuição e manutenção continuam exigindo trabalho real;
- se a loja encher de software raso, o filtro fora do código tende a pesar ainda mais.
Um comentário resumiu isso de forma quase brutal: hoje está “incredibly easy to make apps”, então o jogo passa a ser distribuição. Outro ponto recorrente foi que o app bom ainda depende de contexto, revisão, integração e produto — coisas que a IA ajuda, mas não resolve sozinha.
Em outras palavras: o teclado ficou mais rápido, mas o funil não ficou mais leve.
A Apple deixa isso explícito na própria documentação
Quando você sai do debate e vai para as fontes oficiais, a tese fica ainda mais concreta.
Nas App Review Guidelines, a Apple reforça que a App Store é um ambiente curado, com review humano, checagem de segurança e critérios para conteúdo, performance, design e legal. A parte mais útil, porém, está no que ela trata como erro comum: app incompleto, placeholder, link quebrado, informação faltando, serviço de backend inacessível e fluxo mal explicado.
Na página oficial de App Review, a Apple diz que, em média, 90% das submissões são revisadas em menos de 24 horas. Parece rápido — até você ler o resto: mais de 40% dos problemas não resolvidos estão ligados à guideline 2.1, de App Completeness, que cobre crash, conteúdo temporário e informação incompleta.
Esse é o ponto que o hype costuma esconder. O gargalo do app não é só compilar uma interface. É chegar no review com:
- produto realmente funcional;
- metadados corretos;
- fluxo explicável;
- links e política de privacidade certos;
- credenciais ou demo prontos para revisão;
- clareza sobre o que o app faz e por que pede certas permissões.
Se isso falha, a IA não salva o publish.
E o Google Play também não está no modo “manda qualquer coisa”
O lado Android vai na mesma direção, ainda que com outro tom.
A documentação do Google Play avisa que, para certas contas, a revisão pode levar até sete dias ou mais em casos excepcionais. A mesma ajuda oficial detalha estados como In review, Update rejected e App rejected, além de deixar claro que até mudanças em updates entram no fluxo de análise.
Tem outro detalhe que conversa direto com a thread do HN: publicar não é só subir o binário. O Play Console pede configuração de listing, contato, classificação, assets, trilhas de teste e requisitos de release. E a própria documentação lembra que o dashboard passa por conteúdo, testes, pré-lançamento e só depois chega em produção.
Ou seja: no Android também não basta ter um app “que abre”. Você precisa passar por um processo de distribuição que cobra organização, documentação e consistência.
TestFlight virou quase parte do trabalho, não só um detalhe
No mesmo debate, apareceu a sugestão prática que muita gente subestima: usar TestFlight para circular o app antes do lançamento aberto.
A documentação da Apple mostra por quê. Dá para trabalhar com até 100 testadores internos e até 10 mil externos, com grupos, feedback, crash report e revisão específica para builds destinados a testers externos.
Isso muda a leitura do mercado. Se fazer o app-base ficou mais rápido, a etapa de teste real e ajuste antes do publish ganhou mais valor, não menos. O profissional que só sabe chegar até a tela pronta ficou mais vulnerável. O que sabe levar o app por beta, feedback, review e publicação ficou mais valioso.
O trabalho mais importante mudou de lugar
Esse caso da comunidade ajuda a enxergar uma virada que interessa para qualquer pessoa de TI, mesmo fora do mobile.
Quando a produção do código fica mais barata, o valor escapa do trecho mais automatizável e vai para o que continua difícil:
- decidir o que vale construir;
- revisar o que a IA entregou;
- aparar edge case;
- acertar experiência real;
- explicar o produto para a plataforma;
- sobreviver a review, testes e distribuição;
- fazer o usuário descobrir e confiar no app.
É por isso que a sensação de muita gente não é “meu trabalho sumiu”. É “meu trabalho ficou mais espalhado e mais chato”. E, honestamente, faz sentido. Parte da carga saiu do teclado e foi para QA, publicação, ajuste fino e operação.
O recado prático para quem quer trabalhar com apps em 2026
Se você está olhando para mobile agora, talvez a lição mais útil não seja aprender a fazer tela mais rápido. Isso já está ficando barato.
A vantagem real tende a ficar com quem sabe combinar:
- plataforma nativa;
- leitura de produto;
- teste e depuração;
- compliance mínimo de loja;
- assets, copy e metadata sem improviso;
- distribuição e lançamento com menos ruído.
O app simples não morreu. Mas a vida fácil dele, sim.
E isso muda a carreira: em 2026, saber publicar bem pode diferenciar mais do que saber prototipar rápido.
