GBTC: Publique seu app com facilidadeDescubra a GoodBarber Takes Care e simplifique o processo de publicação de apps para a App Store e o Google Play. Deixe-nos lidar com os detalhes técnicos para você.Aprenda mais sobre GBTC
Marc Leonardi
Backend & DevOps Engineer
Sou engenheiro de Backend & DevOps na GoodBarber, onde trabalho nos sistemas e na infraestrutura que sustentam a nossa plataforma no-code de criação de aplicações. Desenvolvo e opero serviços backend, APIs e infraestrutura, com foco em fiabilidade, escalabilidade e automação. Escrevo sobre engenharia backend, DevOps, infraestrutura e os desafios técnicos de operar uma plataforma em grande escala.
Imagine uma rádio local com programas em direto, uma grelha de programação e entrevistas disponíveis a pedido na sua app. Cada gravação tem um título e uma descrição. Estas informações ajudam os ouvintes a explorar os conteúdos, mas uma entrevista contém muitas vezes detalhes úteis que não aparecem no resumo.No nosso exemplo, o episódio chama-se «A cidade que partilhamos». A descrição apresenta uma conversa sobre a vida quotidiana na cidade. Durante a gravação, um urbanista explica as medidas contra o calor no verão: plantar árvores nos percursos para as escolas, criar sombra nos recreios e substituir algumas superfícies pavimentadas por zonas verdes.Nenhuma destas medidas aparece no título ou na descrição. Um ouvinte lembra-se do tema e pergunta:Que episódio explicou como a cidade pretende reduzir o calor no verão?Adicionámos os podcasts áudio às fontes de conhecimento do GoodBarber Chatbot para que perguntas como esta possam levar aos seus programas. Há dois níveis: a informação escrita que publica sobre cada episódio e o conteúdo falado que decide transcrever.
Numa app, publicar um documento útil é apenas uma parte do trabalho. As pessoas também precisam de encontrar a informação certa no momento de agir. Um ficheiro com um nome claro ajuda quem consulta uma biblioteca, mas o leitor pode ter uma pergunta mais imediata.A comunicação interna é apenas uma das aplicações possíveis. A mesma abordagem pode apoiar recursos educativos, guias para membros de uma organização, referências técnicas ou outros documentos úteis partilhados numa app. No nosso exemplo, um colega está a preparar uma visita a um cliente e precisa de saber:Que despesas de viagem exigem aprovação prévia?Adicionámos os documentos às fontes do GoodBarber Chatbot para que os ficheiros que já mantém atualizados possam alimentar estas conversas. A escolha dos documentos é sua. Os utilizadores fazem perguntas pelas suas próprias palavras. O assistente procura as passagens relevantes e utiliza-as para construir uma resposta.A pergunta torna-se uma forma de entrar na política de deslocações. O colaborador pode partir da decisão que precisa de tomar, mesmo sem conhecer o título do documento que a explica.
Um app pode funcionar parcialmente ou completamente sem conexão se os dados e recursos necessários para uma tarefa estiverem disponíveis no dispositivo. Um guia pode exibir uma página aberta antes. Um app de podcasts pode reproduzir um episódio baixado previamente. Uma ferramenta de campo projetada para funcionar primeiro offline pode até registrar uma ação localmente e sincronizá-la depois.Essas são três promessas técnicas diferentes:Conteúdo em cache: um item carregado anteriormente pela rede permanece disponível temporariamente no dispositivo.Conteúdo salvo de propósito: o usuário escolhe um artigo, arquivo de áudio ou outro item compatível para consultar mais tarde.Funcionamento «offline-first»: o app executa todas as suas funções principais, ou uma parte essencial delas, com dados locais. Se também aceitar alterações offline, precisará sincronizá-las e resolver possíveis conflitos quando a conexão voltar.Nossa extensão Offline oferece as duas primeiras abordagens para conteúdo compatível: manter materiais carregados anteriormente disponíveis e permitir que os leitores salvem itens suportados nos Favoritos.Pela definição do Android, um app «offline-first» precisa permitir o uso sem internet de todas as suas funções principais, ou de um subconjunto crítico delas. Essa arquitetura requer fontes de dados locais. Se o app também aceitar alterações offline, precisará de regras de sincronização e de uma forma de lidar com conflitos quando a conexão voltar. É muito mais do que colocar uma página em cache.Essa distinção importa ao escolher um criador de apps ou descrever o seu próprio app. «Disponível offline» deve indicar uma tarefa específica, sem sugerir que todas as telas e ações funcionem como quando há conexão.
Imagine uma associação profissional que publica uma notícia sempre que alguém encontra tempo: três atualizações durante a semana de um congresso e depois um mês de silêncio. Os associados não conseguem prever como o app os ajudará. A equipe editorial também não sabe qual trabalho vale a pena continuar.Uma estratégia de conteúdo para apps móveis define o resultado que o conteúdo deve produzir, as necessidades recorrentes às quais responderá, os formatos e o ritmo que a equipe consegue manter, como as publicações serão distribuídas e quais sinais disponíveis levarão a uma decisão.Este guia trata do conteúdo publicado e consumido dentro de um aplicativo móvel, não do marketing de conteúdo usado para promovê-lo. Capturas nas lojas, campanhas de aquisição e publicações nas redes sociais podem atrair usuários. A estratégia discutida aqui começa depois que eles chegam.O calendário é apenas o resultado visível. A estratégia é o raciocínio que decide o que merece ocupar um lugar nele.
Imagine um app de cursos. Um novo aluno chega porque quer fazer uma aula curta sobre um assunto específico. Antes de começar, o app apresenta cinco telas introdutórias, pede que ele se cadastre, solicita permissão para notificações e abre em um feed de notícias genérico. Cada tela pode ter sido bem projetada, mas a primeira sessão falhou: o aluno ainda não encontrou uma aula.O onboarding mobile é a jornada desde a primeira abertura até um resultado útil inicial: o primeiro valor. Concluir a ação que entrega esse resultado é a ativação.TermoO que descreveExemplo no app de cursosOnboardingTodo o caminho entre a primeira abertura e o primeiro valorAbrir o app, encontrar uma aula e iniciá-laPrimeiro valorO resultado útil inicial que o usuário buscavaChegar a uma aula adequada ao objetivo do alunoAtivaçãoA ação observável que indica o primeiro valorIniciar essa aulaO onboarding costuma ser reduzido ao passo a passo exibido na primeira abertura, mas os dois conceitos não são equivalentes. Um passo a passo é apenas uma forma de apoiar a jornada: uma sequência curta de telas introdutórias que fornece o contexto essencial antes da entrada no app. No GoodBarber, a extensão Passo a passo do app permite criar essa introdução; a necessidade depende do que existe entre o novo usuário e o primeiro valor.Não comece decidindo quais telas introdutórias criar. Primeiro, pergunte o que um novo usuário deve conseguir fazer. Esse objetivo define a jornada de onboarding e determina se um passo a passo, orientações contextuais ou o acesso direto são a opção mais adequada.As orientações da Apple para onboarding recomendam tornar o app compreensível por meio do uso e manter qualquer fluxo introdutório breve e opcional. Um passo a passo ajuda quando elimina uma incerteza; caso contrário, apenas atrasa o acesso ao produto.
O projeto Mobile Application Security da OWASP abrange áreas técnicas como armazenamento, criptografia, autenticação, comunicação de rede e resistência à engenharia inversa. Os proprietários de apps trabalham normalmente noutro nível: acesso, funcionalidades ativas, serviços ligados e gestão de alterações.Segurança, privacidade e conformidade sobrepõem-se, mas respondem a perguntas diferentes:ÁreaPergunta principalSegurançaComo são protegidas as contas, os dados, os serviços e os acessos contra utilização indevida?PrivacidadeQue dados pessoais são utilizados, porquê e que escolhas têm as pessoas?ConformidadeQue regras legais, contratuais e das lojas se aplicam a esta app?Uma app pode descrever corretamente as suas práticas de dados e continuar a conceder acessos demasiado amplos. A aprovação das lojas não é um certificado de segurança. Este guia fornece uma base operacional; dados sensíveis, processos regulamentados ou muito código personalizado podem exigir uma avaliação qualificada.
Um professor procura documentos para o pessoal, um pai consulta o calendário e um aluno guarda um guia para um trabalho. Enviar todos os avisos aos três seria fácil, mas cada vez menos útil. A questão relevante não é quantos dados pode recolher. É saber que parte da experiência deve realmente mudar:algumas secções são partilhadas, enquanto outras dependem do papel do utilizador;as notificações chegam apenas ao público em causa;cada mensagem chega no momento adequado e abre um destino útil;os utilizadores escolhem as atualizações recorrentes e os conteúdos que pretendem guardar.Isto é personalização prática de uma app móvel. Não é necessário qualquer modelo de pontuação opaco.
“Você está perto da nossa loja. Venha nos visitar!”Essa mensagem sabe onde uma pessoa está, mas não por que a interrupção seria relevante. Ela não oferece um valor específico nem um próximo passo. Na melhor das hipóteses, o marketing baseado em localização usa a proximidade como contexto, não como toda a estratégia.Agora compare com esta mensagem:“Seu pedido está pronto. Você está perto do ponto de retirada — mostre esta mensagem no balcão.”A segunda mensagem conecta uma pessoa conhecida, um lugar relevante, o momento certo e uma ação imediata. A mesma lógica pode orientar uma visita a um museu, um alerta em um evento ou um serviço local — não apenas uma promoção.
O número de downloads costuma se tornar o principal indicador após o lançamento. Mas ele registra aquisição, não toda a relação entre um usuário e seu aplicativo.Uma pessoa pode instalar o app e nunca mais abri-lo. Outra pode voltar todas as manhãs, ler vários artigos e responder às notificações. Contar ambas como um download esconde a diferença que realmente importa.O mesmo cuidado vale para qualquer métrica isolada. Mais visualizações de página podem indicar uma exploração útil ou uma navegação confusa. Uma sessão mais longa pode representar uma escuta atenta ou atrito em uma tarefa que deveria levar poucos segundos. Pergunte qual comportamento produziu o número e qual decisão ele pode orientar.
Não é possível comprovar que um app é acessível por meio de uma prévia ou de uma pontuação de contraste. No entanto, é possível remover uma quantidade surpreendente de barreiras antes do início dos testes formais.A acessibilidade móvel vai muito além do contraste de cores. Tipografia, espaçamento, navegação, áreas de toque, rótulos, movimento, mídia e comportamento com tecnologias assistivas também determinam se uma pessoa consegue concluir uma tarefa.As WCAG foram escritas para conteúdo web. As orientações WCAG2Mobile do W3C explicam como aplicar os critérios de nível A e AA das WCAG 2.2 a apps móveis nativos, web e híbridos. O documento é informativo, não uma norma móvel separada, e sozinho não basta para estabelecer que um app seja acessível.Esta checklist separa o que pode ser configurado de forma centralizada do que ainda precisa ser verificado no produto publicado:Área de acessibilidadePrimeira verificaçãoO que configurar ou testarContraste de coresTextos, fundos, controles e estadosDefinir as cores globais e verificar cada combinação de contrasteTipografia e espaçamentoPadrões legíveis, quebra de linha e ampliaçãoConfigurar a hierarquia tipográfica e as margens globaisNavegaçãoDestinos e rótulos clarosConfigurar a estrutura, os rótulos e a navegação do appÁreas de toqueControles fáceis de operarVerificar o app gerado em dispositivosLeitores de telaNomes, funções, estados e ordem de focoTestar os apps iOS e Android geradosMovimentoEfeitos úteis e opcionaisConfigurar animações e resposta tátil e testar as preferências do sistemaMídiaLegendas, transcrições e alternativas em textoAdicionar alternativas durante a criação e a revisão editorialInteração PWATeclado, zoom, foco e layouts responsivosTestar a PWA publicada em navegadores
Imagine o app de um personal trainer com contas de membros, localização opcional, um formulário de e-mail e analytics. Já são quatro fluxos de dados diferentes. Basta alterar um recurso para que o cenário de privacidade também mude.A parte mais difícil não é criar uma página jurídica. É fazer com que três elementos descrevam o mesmo app:ElementoO que deve refletirO próprio appOs dados, as permissões e os serviços de terceiros realmente utilizadosA política de privacidadeO que é coletado, por quê, por quem, por quanto tempo e o que os usuários podem fazer a respeitoAs declarações nas lojasAs respostas de Privacidade do App da Apple e Segurança dos dados do Google Play com base na versão atual do appSe um desses elementos disser “nenhum dado de localização” enquanto o app enviado solicitar acesso à localização, existe uma inconsistência.Grande parte da preparação de privacidade consiste em verificar a coerência: o app, a política e a página da loja precisam contar a mesma história. Essa coerência é necessária, mas não substitui o cumprimento das regras de privacidade e dados do usuário das lojas.Este artigo ajuda você a preparar essa história. Ele não oferece aconselhamento jurídico: os requisitos aplicáveis variam conforme o país, o público e o tipo de dado.