UC02646

Apps móveis no-code

Glide, Adalo, FlutterFlow, Thunkable

Curso profissional · 25h · Mobile sem código

Plano

  1. Mobile no-code — landscape
  2. PWAs vs nativo vs híbrido
  3. Glide — apps de spreadsheets
  4. Adalo — apps nativas
  5. FlutterFlow — Flutter visual
  6. Thunkable — block-based
  7. Backend, auth, push
  8. Publicação stores

Bloco 1 · Mobile no-code

Por que existe

  • Apps nativas (Swift, Kotlin): caras, demoradas (meses).
  • App stores: friction de submissão, review.
  • PWAs + plataformas no-code abriram porta a "qualquer pessoa".
  • Mercado: empreendedores, internal tools, MVPs validados antes de investir dev.

Vantagens

✅ MVP em dias vs meses.
✅ Sem dependência de developers iOS/Android.
✅ Iteração rápida (mudar UI em minutos).
✅ Hosting + auth + DB incluídos.
✅ Stores publicação suportada.

Limites

❌ Performance limitada vs nativo.
❌ Lock-in à plataforma.
❌ Customização tem tecto.
❌ Custo escala (free tiers limitados).
❌ Features avançadas (AR, ML, hardware-deep) raras.

Quando faz sentido

  • MVP de startup antes de validar.
  • App interna empresa (catálogo, gestão de pedidos).
  • Eventos (conferências, festivais — guia).
  • Directórios (membros, locais).
  • Educação (cursos com vídeos).
  • Pequeno comércio (catálogo + pedidos).

Bloco 2 · Tecnologias mobile

Tipos de app móvel

  • Nativo: Swift (iOS) ou Kotlin (Android). Performance máxima, acesso total a hardware.
  • Cross-platform: React Native, Flutter — código JS/Dart que compila para nativo.
  • Híbrido: HTML/JS dentro de webview (Cordova, Ionic).
  • PWA (Progressive Web App): site web instalável, sem stores.

No-code platforms produzem uma destas.

PWA — instalável sem stores

  • HTML+JS+CSS.
  • Service worker para offline.
  • Manifest para "install".
  • Funciona em iOS e Android.
  • Sem submissão a stores.

Glide, Bubble usam PWA. Grande vantagem: deploy instantâneo.

Bloco 3 · Glide

Conceito

Glide (glideapps.com): Google Sheet → app mobile bonita em minutos.

Workflow:

  1. Spreadsheet com dados.
  2. Glide conecta e auto-gera UI.
  3. Customizar visualmente.
  4. PWA publicado.

Free com limites. Pro $25-249/mês.

Exemplo rápido

  1. Google Sheet "Catálogo": colunas Nome, Preço, Foto (URL), Categoria.
  2. glideapps.com → New App → "From Google Sheets" → escolher.
  3. Glide gera lista + detalhe automáticos.
  4. Customizar:
    • Tabs: Lista, Mapa, Perfil.
    • Components: Image, Title, Subtitle, Button.
    • Actions: chamar, email, share, open URL.
  5. Share → PWA URL → instalar no telemóvel.

10 minutos até protótipo apresentável.

Glide features avançadas

  • Computed columns: cálculos sem sheet (price * tax, etc.).
  • User profiles: cada user vê só os seus dados.
  • Forms: submissões públicas.
  • Notifications: push (pago).
  • Payments: Stripe integrado.

Bloco 4 · Adalo

Apps mobile nativas

Adalo (adalo.com): apps publicáveis em App Store e Google Play.

Diferença vs Glide:

  • Glide = PWA.
  • Adalo = app nativa real (com IPA / APK).

Drag-drop editor, BD própria, actions visuais, pricing $36+/mês.

Workflow Adalo

  1. New App → escolher template (lista, marketplace, social, etc.).
  2. Screens (canvas para cada ecrã).
  3. Components (Text, Image, Button, Form).
  4. Database: tipos, fields, relations.
  5. Actions: navigate, create record, send email.
  6. Test no browser ou app Adalo Companion (telemóvel).
  7. Publish:
    • Web: domínio Adalo gratuito.
    • iOS: precisa Apple Developer ($99/ano).
    • Android: precisa Google Play ($25 one-time).

Bloco 5 · FlutterFlow

Visual Flutter

FlutterFlow (flutterflow.io): editor visual que gera código Flutter real.

Diferença chave: podes exportar código e continuar dev tradicional. Sem lock-in absoluto.

  • Drag-drop UI.
  • Firebase integrado (auth, BD, storage).
  • Custom code (Dart) onde precisas.
  • Export para projecto Flutter completo.

Quando usar FlutterFlow

✅ Querer flexibilidade de escapar para código.
✅ Performance importa (Flutter é nativo).
✅ Team com Flutter skills future.
✅ Apps complexas mas começa visual.

Pricing $30-70/mês.

Bloco 6 · Thunkable / outras

Thunkable

Editor block-based (visual à la Scratch).

  • Excelente para iniciantes / educação.
  • Cross-platform iOS + Android + Web.
  • Free com branding; pago para publicar.

AppGyver (SAP)

  • Free.
  • Mais sério, com lógica avançada.
  • Aprende um pouco mais íngreme.
  • Output para nativo.

Bravo

  • Importa de Figma directamente.
  • Designers transformam designs em apps.

Comparação rápida

Plataforma Tipo Free Curva
Glide PWA Sim (limitado) Muito fácil
Adalo Nativo Sim (limitado) Fácil
FlutterFlow Nativo (Flutter) Limitado Média
Thunkable Nativo Sim Muito fácil
Bubble Web (PWA mobile-friendly) Sim Média

Bloco 7 · Backend, auth, push

Autenticação

A maioria das plataformas inclui:

  • Email + password.
  • Magic link (email).
  • Google / Apple / Facebook (OAuth).
  • Phone OTP (custos extra).

Configurar é 5 cliques.

Base de dados

Cada plataforma tem o seu:

  • Glide: Sheet ou Glide Tables.
  • Adalo: BD interna.
  • FlutterFlow: Firebase (Firestore).
  • Bubble: BD interna.

Para escala / integrações: conectar a Airtable, Supabase, ou backend custom via API.

Push notifications

  • Adalo: nativo, simples.
  • Glide: pago, vai por OneSignal.
  • FlutterFlow: Firebase Cloud Messaging.
  • Bubble: plugins (OneSignal).

Boas práticas: opt-in claro, sem spam.

Bloco 8 · Stores

Publicar no Google Play

  1. Conta Google Play Console ($25 one-time).
  2. Gerar AAB / APK da plataforma.
  3. Preencher ficha: descrição, screenshots (mínimo 2), ícone.
  4. Política de privacidade (URL obrigatório).
  5. Submit → review (algumas horas).

Publicar na App Store

  1. Apple Developer Program ($99/ano).
  2. Gerar IPA na plataforma.
  3. Xcode (ou plataforma) sobe para App Store Connect.
  4. Screenshots de vários tamanhos.
  5. Privacy policy + data handling disclosures.
  6. Review (1-3 dias geralmente).

Mais rigoroso que Google. Apple rejeita por motivos variados — ter paciência para correcções.

PWA alternativa

PWAs não precisam de stores:

  • Site web hospedado (pode ser do próprio Glide/Bubble).
  • Add to Home Screen no telemóvel.
  • Funciona offline (com service worker).
  • Updates instantâneos.

iOS suporta PWAs mas com limites (sem push antigamente, melhorou).

UC02646 · resumo

  • Mobile no-code = MVP móvel em dias.
  • Glide: spreadsheet → PWA bonita.
  • Adalo: apps nativas publicáveis.
  • FlutterFlow: Flutter visual com escape para código.
  • Thunkable: block-based, educativo.
  • Stack típico: plataforma + BD + auth + push + analytics.
  • Stores: Google Play barato, App Store $99/ano.
  • PWAs evitam stores, deploy instantâneo.
  • Conhecer estas plataformas dá autonomia mobile sem aprender Swift/Kotlin.

NOTAS DO PROFESSOR 📖 Por que existe o mobile no-code O no-code mobile nasceu de um problema real: desenvolver apps nativas é caro e lento, e nem toda a gente tem equipa de developers. Estas plataformas baixaram a barreira de entrada para empreendedores e empresas que precisam de validar uma ideia depressa. Convém enquadrar isto como ferramenta de validação, não como substituto definitivo do desenvolvimento. 🗣️ Pontos a desenvolver oralmente • Explicar o custo e o tempo de uma app nativa tradicional. • Dar exemplos de internal tools que não precisam de loja. • Discutir o conceito de MVP e validar antes de investir.

NOTAS DO PROFESSOR 📖 Vantagens e limites — escolher com olhos abertos O no-code é poderoso para velocidade, mas tem tectos reais: performance, customização e lock-in à plataforma. O ponto pedagógico é equilibrar o entusiasmo com lucidez — saber o que estas ferramentas não fazem é tão importante como saber o que fazem. Os formandos devem aprender a recomendar a ferramenta certa em vez de a "moda". 🗣️ Pontos a desenvolver oralmente • Explicar o que é lock-in e por que pesa a longo prazo. • Dar exemplos de funcionalidades que o no-code não cobre bem. • Discutir como os free tiers limitados afectam o custo real.

NOTAS DO PROFESSOR 📖 Casos de uso ideais para no-code O no-code brilha em apps de conteúdo e gestão: catálogos, directórios, guias de evento, cursos. São casos onde a lógica é simples e o valor está nos dados e na interface. Pedir aos formandos que identifiquem, no seu contexto, uma app interna que poderiam construir ajuda a tornar o conceito concreto. 🗣️ Pontos a desenvolver oralmente • Pedir exemplos de apps de evento ou directório conhecidas. • Discutir uma app interna útil para uma pequena empresa local. • Distinguir casos "bons" de casos que exigem desenvolvimento real.

NOTAS DO PROFESSOR 📖 Os tipos de app móvel Compreender estas categorias é essencial para perceber o que cada plataforma no-code realmente entrega por baixo. Nativo dá performance máxima mas exige Swift/Kotlin; cross-platform e híbrido equilibram; o PWA dispensa lojas. Os formandos precisam deste mapa para não confundir "app" com "app nativa". 🗣️ Pontos a desenvolver oralmente • Posicionar React Native e Flutter como cross-platform. • Explicar o que distingue híbrido (webview) de nativo. • Antecipar que cada plataforma do curso produz um destes tipos.

NOTAS DO PROFESSOR 📖 PWA — a app sem loja A PWA é a chave para entender plataformas como o Glide: é um site instalável que funciona offline e dispensa submissão às lojas. A grande vantagem é o deploy instantâneo — qualquer alteração fica disponível de imediato, sem esperar review. Vale a pena demonstrar o "Add to Home Screen" num telemóvel em sala. 🗣️ Pontos a desenvolver oralmente • Explicar o papel do service worker no funcionamento offline. • Demonstrar a instalação de uma PWA no telemóvel. • Contrastar deploy instantâneo com a espera de review nas lojas.

NOTAS DO PROFESSOR 📖 Glide — da spreadsheet à app O conceito central do Glide é genial pela simplicidade: os dados vivem numa Google Sheet e a app gera-se a partir deles. Quem sabe usar uma folha de cálculo já tem metade do caminho feito. Reforçar que a estrutura da spreadsheet (colunas bem nomeadas) determina diretamente a qualidade da app gerada. 🗣️ Pontos a desenvolver oralmente • Mostrar como uma coluna na sheet vira um campo na app. • Explicar que organizar bem a folha é organizar bem a app. • Enquadrar os limites do plano free para projectos reais.

NOTAS DO PROFESSOR 📖 Construir uma app Glide na prática Este é o exercício que mostra o poder do no-code: em minutos, sai um protótipo apresentável. O segredo está em começar pelos dados e depois compor a UI com tabs, components e actions. Acompanhar os formandos passo a passo neste exemplo é a melhor forma de desbloquear a autonomia deles. 🗣️ Pontos a desenvolver oralmente • Fazer o exercício ao vivo, do Sheet à PWA. • Explicar a diferença entre tabs, components e actions. • Mostrar uma action prática (chamar, partilhar, abrir URL).

NOTAS DO PROFESSOR 📖 Glide além do básico As funcionalidades avançadas mostram que o Glide não é só uma lista bonita: computed columns, perfis de utilizador e pagamentos transformam-no numa ferramenta de produto real. As computed columns são especialmente úteis porque evitam poluir a spreadsheet com fórmulas. Levar os formandos a ver onde estas features acrescentam valor sem complicar. 🗣️ Pontos a desenvolver oralmente • Dar um exemplo de computed column (preço com IVA). • Explicar user profiles para apps com dados privados. • Mencionar que push e pagamentos pertencem aos planos pagos.

NOTAS DO PROFESSOR 📖 Adalo — apps nativas publicáveis A grande distinção face ao Glide é que o Adalo gera apps nativas reais (IPA/APK), publicáveis nas lojas. Isto abre a porta a produtos que precisam de estar na App Store ou Google Play. Em troca, ganha-se complexidade: há base de dados própria, ecrãs e actions a desenhar. Convém posicionar o Adalo como o passo seguinte em ambição. 🗣️ Pontos a desenvolver oralmente • Clarificar PWA (Glide) vs app nativa (Adalo). • Explicar quando vale a pena estar na loja vs PWA. • Antecipar os custos de publicação que vêm a seguir.

NOTAS DO PROFESSOR 📖 O fluxo de trabalho do Adalo O workflow do Adalo introduz conceitos de desenvolvimento de software: ecrãs, componentes, base de dados com relações e actions de navegação. É um bom momento para os formandos perceberem o que é uma relação entre tabelas. O Adalo Companion permite testar no telemóvel real, o que motiva muito a turma. 🗣️ Pontos a desenvolver oralmente • Explicar o que é uma relação na base de dados com um exemplo. • Demonstrar o teste no Adalo Companion ao vivo. • Reforçar que iOS e Android têm custos de conta separados.

NOTAS DO PROFESSOR 📖 FlutterFlow — visual com escape para código O FlutterFlow resolve o maior receio do no-code: o lock-in. Como gera código Flutter real e exportável, um projecto pode começar visual e continuar em desenvolvimento tradicional. É a ponte entre o no-code e o low-code/pro-code. Para turmas com ambições técnicas, é a plataforma mais interessante de explorar. 🗣️ Pontos a desenvolver oralmente • Explicar o que significa "exportar código" e por que liberta. • Posicionar o Firebase como backend integrado. • Distinguir no-code puro de low-code com custom Dart.

NOTAS DO PROFESSOR 📖 Quando o FlutterFlow é a escolha certa A decisão por FlutterFlow faz-se quando a flexibilidade futura e a performance importam. Se a app pode crescer em complexidade ou a equipa pode ganhar competências Flutter, vale a curva de aprendizagem extra. Ensinar os formandos a escolher a ferramenta pelo destino do projecto, e não pela facilidade imediata, é o objectivo deste slide. 🗣️ Pontos a desenvolver oralmente • Listar sinais de que um projecto vai exigir performance nativa. • Discutir o trade-off entre curva de aprendizagem e flexibilidade. • Comparar FlutterFlow com Glide num mesmo cenário hipotético.

NOTAS DO PROFESSOR 📖 Thunkable — block-based e educativo O Thunkable usa blocos visuais ao estilo Scratch, o que o torna excelente para introduzir lógica de programação sem sintaxe. É a porta de entrada ideal para quem nunca programou. Reforçar que os blocos ensinam pensamento lógico (condições, eventos) que depois transita para qualquer linguagem. 🗣️ Pontos a desenvolver oralmente • Relacionar os blocos do Thunkable com a lógica do Scratch. • Explicar por que o block-based é bom para iniciantes. • Mostrar um bloco de evento simples (ao clicar → fazer X).

NOTAS DO PROFESSOR 📖 Outras plataformas do ecossistema O panorama no-code é vasto e cada plataforma tem um nicho: AppGyver para lógica mais séria, Bravo para designers que partem do Figma. Conhecer as alternativas evita que os formandos fiquem presos a uma só ferramenta. O caso do Bravo é interessante para mostrar a ponte entre design e produto funcional. 🗣️ Pontos a desenvolver oralmente • Explicar o fluxo Figma → Bravo → app para designers. • Posicionar o AppGyver como opção gratuita mais avançada. • Incentivar a curiosidade por novas plataformas que vão surgindo.

NOTAS DO PROFESSOR 📖 Comparar para escolher Esta tabela é a ferramenta de decisão do módulo: cruza tipo de output, custo e curva de aprendizagem. O objectivo não é decorá-la, mas saber consultá-la perante um briefing concreto. Propor cenários ("app interna grátis e rápida", "produto na loja com performance") e pedir à turma que escolha a coluna certa. 🗣️ Pontos a desenvolver oralmente • Percorrer a tabela coluna a coluna com um exemplo. • Propor cenários e pedir a escolha justificada da plataforma. • Relembrar que "fácil" nem sempre é "adequado".

NOTAS DO PROFESSOR 📖 Autenticação incluída de origem Uma das grandes poupanças do no-code é a autenticação pronta a usar: email/password, magic link e OAuth com Google ou Apple ficam a poucos cliques. Construir isto de raiz exigiria conhecimento de segurança considerável. Aproveitar para explicar por que o OAuth é mais seguro e cómodo que gerir passwords. 🗣️ Pontos a desenvolver oralmente • Explicar o que é OAuth e por que evita guardar passwords. • Comparar magic link com password tradicional. • Alertar para os custos extra do phone OTP por SMS.

NOTAS DO PROFESSOR 📖 Onde vivem os dados da app Cada plataforma traz a sua base de dados, mas o ponto importante é que, quando a app cresce, se pode conectar a backends externos via API (Airtable, Supabase). Isto evita o tecto de escala. Os formandos devem perceber que a base de dados é o coração da app e que a sua escolha condiciona o futuro do projecto. 🗣️ Pontos a desenvolver oralmente • Relacionar cada plataforma com a sua base de dados nativa. • Explicar quando se justifica conectar a Airtable ou Supabase. • Introduzir a noção de API como ponte entre sistemas.

NOTAS DO PROFESSOR 📖 Push notifications com responsabilidade As notificações push são uma arma de dois gumes: aumentam o envolvimento mas, mal usadas, levam o utilizador a desinstalar. A boa prática é o opt-in claro e o respeito pela atenção do utilizador. Tecnicamente, cada plataforma vai por um serviço (OneSignal, Firebase), o que convém referir como detalhe de implementação. 🗣️ Pontos a desenvolver oralmente • Discutir o equilíbrio entre envolvimento e spam. • Explicar a importância do opt-in explícito e da privacidade. • Mencionar OneSignal e Firebase como motores de push.

NOTAS DO PROFESSOR 📖 Publicar no Google Play A publicação na Google Play é o lado mais acessível das lojas: conta única de 25 dólares, review rápido e processo direto. Mesmo assim, exige ficha bem preenchida e — ponto crítico — uma política de privacidade com URL obrigatório. Os formandos devem sair daqui a saber que publicar não é só carregar o ficheiro: é cumprir requisitos legais e de apresentação. 🗣️ Pontos a desenvolver oralmente • Realçar a obrigatoriedade da política de privacidade. • Explicar a diferença entre AAB e APK. • Dar dicas para screenshots e ícone que convertem downloads.

NOTAS DO PROFESSOR 📖 Publicar na App Store A App Store é mais exigente: 99 dólares por ano, review mais demorado e critérios apertados que levam a rejeições frequentes. Preparar a turma para encarar a rejeição como parte normal do processo, não como falhanço. As disclosures de privacidade e o tratamento de dados são pontos onde a Apple é particularmente rigorosa. 🗣️ Pontos a desenvolver oralmente • Contrastar custo e rigor entre Apple e Google. • Normalizar a rejeição e o ciclo de correcções. • Explicar as data handling disclosures exigidas pela Apple.

NOTAS DO PROFESSOR 📖 PWA como alternativa às lojas A PWA fecha o círculo do módulo: para muitos projectos, evitar as lojas é uma vantagem, não uma limitação. Sem submissão, sem custos de conta, com updates instantâneos. O contraponto honesto é que o iOS impõe limites, embora venham a diminuir. A lição é avaliar caso a caso se a loja é mesmo necessária. 🗣️ Pontos a desenvolver oralmente • Resumir as vantagens da PWA face às lojas. • Ser honesto sobre os limites históricos do iOS. • Pedir à turma que decida loja vs PWA para um projecto dado.