Se a meta é um ícone na App Store ou na Play Store, o caminho que o mercado usa é Bolt com Expo ou FlutterFlow. A FlexPage não publica nessas lojas, não gera projeto Expo e não entrega SDK mobile. O que ela faz no celular é outro produto — e esta página diz qual.
“Mobile” na busca quase sempre significa binário, revisão da Apple ou do Google, push nativo, câmera do sistema. A FlexPage não promete nenhum desses. Promete a página responsiva e, se você já tem o app, uma API para o agente.
Bolt, quando o projeto é Expo, e FlutterFlow são as ferramentas que o mercado associa a app iOS e Android: gerar a interface, empacotar e seguir o fluxo de publicação da loja. O código ou o projeto fica com quem constrói, para submeter à App Store e à Play Store.
Se o pedido inclui “quero na loja”, “quero o ícone na tela inicial sem ser atalho de site” ou “preciso do binário”, essas ferramentas continuam no caminho. A FlexPage não compete nesse pedido.
Sessão App cria telas em www/ e a API em script/. O cliente entra pelo link, no Chrome ou no Safari, e usa a mesma página que o desktop usa — desenhada primeiro para a tela pequena. Hospedagem e SSL já estão no domínio.
Não há fila de revisão da loja porque não há pacote para revisar. Atualizar a tela é aprovar um arquivo, não esperar a Apple ou o Google.
No mapa de um app, a primeira peça é “cliente no celular”: escolhe corte, barbeiro, dia e horário. A peça seguinte é a tela em www/, que pergunta os horários à API em script/. Nada nessa cadeia é um aplicativo instalado.
A pessoa abre o endereço do domínio. Pode fixar na tela inicial do celular como atalho do navegador — isso continua sendo site, não app publicado.
HTML e JavaScript responsivos. O mesmo arquivo serve o celular e o computador. A hierarquia e o toque são pensados para o dedo, não para um framework nativo.
Horário livre, pedido, login: o servidor do domínio responde. A tela não carrega um SDK da loja. Os dados ficam em sandbox/ ou no banco que você ligar.
Lembrete de horário, confirmação, mensagem depois do atendimento: o servidor roda sozinho. No exemplo do guia, isso sai pelo WhatsApp, não por notificação push da loja.
Página rápida de abrir, sem download, sem atualização pela loja, com SSL. Formulário, lista, agendamento e chat do agente funcionam no navegador. Quem já usa o site no computador usa o mesmo endereço no telefone.
Não há publicação na App Store nem na Play Store. Não há projeto Expo. Não há promessa de push nativo, compra dentro do app da loja, acesso profundo à câmera ou aos contatos como um binário nativo faz. Se o produto depende disso, a FlexPage não é a ferramenta.
O agente atende no chat do site, no WhatsApp ou por API. O cliente fala pelo aplicativo que já tem instalado. Isso cobre muita demanda de “quero no celular” sem inventar um binário. Não cobre um produto que só existe como app de loja.
O desenho das peças — tela, API, dados, rotina — está na lição Entendendo um app por dentro. Vale ler antes de pedir “um app”, para o pedido nomear a tela e o servidor, não uma loja.
O guia descreve um caso concreto: a empresa já tem um app de celular próprio, ou um sistema de caixa, e quer usar os mesmos agentes pela API HTTP. A FlexPage entra aí como o cérebro da conversa, não como o pacote que sobe na loja.
| Quem faz | O quê | Onde mora |
|---|---|---|
| O app que você já tem | Tela nativa, ícone, revisão da loja, o que o binário precisa fazer. | No projeto Expo, Flutter ou nativo — fora da FlexPage. Ela não gera esse projeto. |
| O servidor desse app | Guarda a chave e chama a API. O guia é explícito: a chave não fica no app instalado no celular. | No backend que você controla, não no HTML da loja e não no aparelho do cliente. |
| O agente da FlexPage | Responde com as funções do site: horário, pedido, texto. Comando fp-agent-run, chave Bearer, resposta em JSON. |
No domínio FlexPage. A página Agentes por API descreve a chamada. |
| O Harness | Constrói o agente, as funções e as telas web. Não escreve SQL livre no lugar do agente. | No painel, nas pastas do domínio. Quem atende o cliente é o agente, não o Harness. |
HTTP, com Authorization: Bearer e o comando fp-agent-run. A lição do guia lista também continuar uma ação, consultar status, ler ou apagar histórico, cancelar e listar agentes. Chave errada ou revogada devolve 401. Não há SDK de iOS nem de Android documentado — e esta página não inventa um.
Não é um componente visual para colar no Expo. Não é ponte com FlutterFlow. Não é permissão para embutir a chave no aplicativo que o cliente instala: o guia manda a chave ficar só no servidor do outro sistema. Quem descumpre isso expõe a chave no aparelho.
Não. O app da FlexPage é web: o cliente abre no navegador, inclusive no celular. Não há binário iOS ou Android, não há publicação na loja e não há projeto Expo. Bolt com Expo e FlutterFlow são o caminho que o mercado usa para app de loja. A FlexPage não se conecta a eles.
A página é responsiva e o cliente abre no navegador do celular, como qualquer site. No guia, o exemplo da barbearia mostra a pessoa escolhendo corte, barbeiro, dia e horário pelo celular, na tela em www/, com a API em script/. Não é um ícone instalado pela loja. Atalho na tela inicial continua sendo site.
Pode chamar os agentes por API HTTP, com chave Bearer e o comando fp-agent-run. O guia diz para guardar a chave só no servidor do outro sistema, nunca no app instalado no celular. A FlexPage não entrega SDK mobile. O contrato da chamada está em Agentes por API e na lição Agentes em outros sistemas.
Não. Sessão App cria telas web em www/ e API em script/. Sessão Projeto pode escrever um programa em qualquer linguagem para você baixar, mas o Harness não executa esse programa no servidor — e isso não é um projeto de loja pronto para submeter.
Sim, no que a home descreve: o agente atende no chat do site, no WhatsApp ou por API HTTP. Quem constrói é o Harness; quem conversa com o cliente é o agente. Isso não substitui um app nativo com push da loja, câmera nativa ou pagamento dentro do app da Apple ou do Google.