Criar aplicativo com IA para Android: o que sai de verdade

Criar aplicativo com IA para Android: o que sai de verdade

A IA monta um aplicativo web: ele abre por um link no navegador do celular, vai para a tela inicial com um toque e se comporta como qualquer outro app. O que não aparece por esse caminho é um APK para a Google Play, que exige conta de desenvolvedor e um processo à parte. Na maioria dos usos ninguém percebe a diferença, e abaixo está quando percebe.

O que a pessoa quer dizer com «aplicativo para Android»?

A frase é a mesma, mas atrás dela existem três necessidades diferentes, e confundi-las custa semanas.

A primeira: alguém quer uma ferramenta que ele e alguns conhecidos vão usar pelo celular. Controle de gastos, lista de tarefas, cadastro de clientes, uma calculadora do próprio setor, um guia interno da equipe. A loja não tem papel nenhum aqui, o que falta é algo que funcione por um link.

A segunda: alguém quer estar na Google Play porque é assim que desconhecidos encontram o app. Isso não é construção, é distribuição, e se resolve independentemente de quem escreveu o código.

A terceira: alguém precisa do que só existe em app nativo. Funcionamento completo sem internet, processos em segundo plano, integração profunda com o sistema, gráficos tridimensionais pesados.

A IA resolve a primeira inteira, a segunda pela metade e com passos extras, e a terceira não resolve. Textos que prometem «seu app Android com uma frase» sem marcar essa fronteira prometem por você algo de que não respondem.

App web e APK: no que diferem na prática

A comparação não é sobre tecnologia, e sim sobre o que você percebe como responsável e o que quem usa percebe.

A linha que merece ser lida duas vezes é a terceira. A diferença não está na qualidade do resultado, e sim no fato de que um caminho se mede em horas e o outro em semanas, e o segundo começa por papelada, não por código.

Como montar, passo a passo?

Tudo acontece no navegador, então o caminho é o mesmo pelo computador e pelo celular.

1. Abra zugo.dev e entre com Google ou GitHub. Os créditos iniciais aparecem na hora e cartão não é pedido.
2. Descreva o aplicativo em linguagem comum. Não como um documento técnico, e sim como você explicaria a um colega: quem usa, o que aparece na primeira tela, o que precisa ser lembrado entre uma visita e outra.
3. Espere a construção. A verificação é feita executando o app em um ambiente isolado, não olhando se ele parece pronto.
4. Abra a prévia e use como um usuário de verdade usaria. Preencha o formulário, aperte no lugar errado, recarregue a página e confira se os dados continuam lá.
5. Corrija escrevendo a próxima mensagem: «coloque uma busca acima da lista», «excluir deve pedir confirmação», «a data já vem com o dia de hoje».
6. Publique. O aplicativo ganha um endereço que abre em qualquer celular.
7. No celular, abra esse endereço e escolha «Adicionar à tela inicial» no menu do navegador. Aparece um ícone, e abrir por ele mostra o app sem a barra de endereço.

O passo sete é exatamente o que a maioria procura ao perguntar sobre Android. Depois dele, distinguir o resultado de um app instalado é quase impossível a olho nu.

Como descrever para a primeira versão chegar mais perto?

Quase toda a distância entre «saiu de primeira» e «estou refazendo há quatro horas» está na primeira mensagem. Três coisas sustentam ela.

Diga quem usa e o que acontece na primeira tela. «Um app de gastos» é um tema, não um pedido. «Abro, vejo um campo de valor e uma lista de categorias, digito o valor, escolho a categoria e o lançamento aparece na lista de hoje» é um pedido.

Diga o que precisa ficar salvo. Esse é o ponto mais caro de mudar depois. Se os lançamentos têm de sobreviver ao fechamento da aba e cada pessoa vê os seus, diga isso já na primeira mensagem: isso se constrói sobre outra base. Como essa base funciona está em a IA consegue criar um app com banco de dados.

Diga o que não deve existir. Restrição economiza mais tempo que exigência. «Sem cadastro, acesso por link» ou «uma tela só, sem menu» cortam ramos inteiros de decisões que depois teriam de ser desfeitas.

O que não ajuda é um documento de uma página. Vinte exigências numa mensagem produzem uma versão em que metade está resolvida por aproximação, e desembaraçar isso demora mais do que acrescentar os mesmos vinte pontos um por um.

Dá para publicar na Google Play?

Dá, e vale dizer em voz alta que é um projeto à parte.

Um aplicativo web pode ser empacotado e enviado como qualquer outro. Para isso é preciso conta de desenvolvedor com taxa única e verificação de identidade, e para contas novas o Google ainda exige teste fechado: um número de testadores tem de usar o app por dias seguidos antes da publicação. Depois vêm a ficha da loja, ícones, capturas e a política de privacidade.

Nada disso é construir. É distribuição e burocracia, e leva no mínimo uma semana. A ordem sensata é publicar o link primeiro, confirmar que as pessoas realmente usam, e só então decidir se a ficha na loja merece essa semana.

Quais aplicativos saem bem e quais não?

Saem bem os que no fundo são formulários, listas e regras entre eles. Controle de gastos, cadastro de clientes, agendamento, checklist de turno, calculadoras internas, captação de contatos, catálogo com filtro, um CRM simples.

Saem mais ou menos os que têm vários papéis com permissões diferentes, aprovações ou relatórios por recortes. Eles são construídos, mas o primeiro resultado é uma base, e o ajuste demora mais que a construção.

Saem mal os que dependem do hardware do aparelho: funcionamento integral sem internet, sincronização em segundo plano, processamento de vídeo no dispositivo, gráficos tridimensionais pesados.

E se depois eu precisar do código?

Essa pergunta vem no começo, não no fim. Muitos construtores entregam o resultado apenas dentro da plataforma deles: enquanto você paga, funciona, e levar embora não dá.

Aqui o código vai para o seu próprio repositório no GitHub, e a partir daí ele é seu: dá para ler, editar à mão, entregar a um programador ou hospedar em outro lugar. Os detalhes estão em dá para exportar o código de um construtor com IA.

A utilidade prática não é ideológica. É que um app feito numa noite deixa de ser um beco sem saída: quando daqui a seis meses aparecer algo que o construtor não faz, você entrega um projeto funcionando em vez de começar do zero.

Quanto custa?

Os créditos iniciais são 2400 e não exigem cartão. Uma construção comum custa cerca de 600 créditos e uma correção cerca de 300. O «cerca de» não é cautela, é precisão: é descontado o gasto real do modelo na sua tarefa, então uma correção curta sai mais barata que uma longa. Quando os créditos iniciais deixam de bastar, existe a assinatura Pro por $25 ao mês com 20000 créditos.

Publicar em um endereço não custa à parte. A conta de desenvolvedor da Google Play, se você acabar indo para a loja, é paga direto ao Google e não tem relação com a construção.

Em resumo

A IA entrega em uma noite um aplicativo que funciona por link, não um arquivo para a Google Play. Para uma ferramenta usada por você, pela sua equipe ou pelos seus clientes isso basta inteiramente: o ícone vai para a tela inicial pelo navegador, e quem usa não percebe diferença. A loja continua sendo tarefa separada, de distribuição e papelada, e faz sentido encará-la quando já existe gente usando o app. Tudo que depende do hardware do celular fica fora desse caminho, e isso é um limite razoável, não um defeito.