Uma base de código. Cinco plataformas. Duas lojas de aplicativos. Quatro navegadores.

Distribuído em menos de três semanas.

Cal.com sempre foi sobre encontrar as pessoas onde elas já estão.

Para agendamento, isso significa em todos os lugares: no seu telefone, no seu navegador, na aba que você nunca fecha, no laptop que você usa para trabalhar e no dispositivo que você pega quando está saindo pela porta.

Muitos de vocês pediram isso e finalmente decidimos tentar. Esta semana anunciámos:

• Um aplicativo nativo para iOS

• Um aplicativo nativo para Android

• Uma extensão para Chrome

• Uma extensão para Firefox

• Uma extensão para Safari

• Uma extensão para Edge

E nós não fizemos isso ao longo de meses ou trimestres.

Distribuímos tudo isso em menos de três semanas, da ideia à produção.

Tudo isso sem dividir o produto em dúzias de repositórios que lentamente se afastam ao longo do tempo.

Fizemos isso com uma única base de código.

A ideia central: distribuir o Cal.com em todo lugar sem distribuir o Cal.com cinco vezes

Historicamente, “aplicativo móvel” e “extensão de navegador” vivem em universos diferentes.

• Mobile quer React Native, ferramentas de construção nativas, fluxos de trabalho de loja de aplicativos, notificações push, deep linking, etc.

• Extensões querem scripts de conteúdo, workers de fundo/serviço, permissões, APIs de armazenamento, peculiaridades do navegador e o interminável jogo “funciona no Chrome mas…”

A abordagem usual é aceitar a divisão:

• equipes separadas

• stacks separados

• processos de lançamento separados

• bugs separados

• inconsistências de UI separadas

Isso não parecia ser o jeito do Cal.com.

Queríamos que o Cal tivesse a sensação de o mesmo produto em todos os lugares. Mesma interface. Mesmo modelo mental. Mesmas funcionalidades. Mesma velocidade de iteração.

Então construímos dessa forma.

iOS + Android: alimentados pelo mais recente Expo e React Native

Nossos aplicativos para iOS e Android são alimentados pelo mais recente Expo (expo.dev) e React Native (RN).

O Expo atingiu um ponto em que você obtém o melhor de ambos os mundos:

• excelente experiência de desenvolvimento

• prontidão séria para produção

• flexibilidade quando você precisa ir para o nativo

Mais importante ainda, o Expo se encaixa em uma tese maior que nos preocupamos profundamente:

Web e nativo não deveriam parecer produtos separados.

Eles deveriam parecer superfícies diferentes do mesmo sistema.

Extensões: alimentadas pelo WXT

Para extensões de navegador, baseamos no wxt.dev.

As extensões ainda são uma daquelas áreas onde as ferramentas podem parecer estranhamente presas no passado. O WXT faz com que pareça moderno:

• estrutura limpa

• padrões sensatos

• construções confiáveis multi-navegador

E sim, criámos para Chrome, Firefox, Safari e Edge.

Só o Safari geralmente é suficiente para assustar as equipas de suporte multi-navegador. Mas o objetivo nunca foi “Chrome agora, outros depois.”

O objetivo era Cal em todos os lugares.

A parte divertida: UI da extensão Chrome alimentada pelo Expo Web

Aqui está a parte que ainda parece um pouco surreal:

Nosso UI da extensão Chrome é alimentado pelo Expo Web.

Isso significa que a UI da extensão não é um front end separado com seu próprio sistema de componentes e diferença de estilo. É construída usando a mesma abordagem de UI que já usamos para móveis rodando na web dentro da superfície da extensão.

Então, quando digo uma base de código, quero dizer de uma forma que realmente importa:

• telas compartilhadas

• componentes compartilhados

• primitivos de design compartilhados

• lógica compartilhada

• velocidade compartilhada

O próprio aplicativo WXT roda dentro de /extension/entrypoints/content.ts que então carrega o aplicativo expo-web como um iframe. Essa é a abordagem mais comum para construir extensões chrome "sidebar" e aprendi esse truque com Wilson Wilson (@euboid). Infelizmente, o "popup" oficial da extensão chrome tem uma altura máxima de 600px.

Nós até implementamos algumas APIs apenas de navegador, como injetar nosso widget Cal.com em mail.google.com e calendar.google.com, o que pode ser facilmente feito na pasta /extensions do WXT.

Da minha experiência, essa combinação: iOS nativo + Android via Expo, extensões multi-navegador via WXT, UI da extensão via Expo Web, tudo unido em uma base de código coerente é algo que eu pessoalmente nunca vi feito assim antes.

Talvez exista em algum lugar. A internet é grande.

Mas eu não vi, e definitivamente não havia um manual que pudéssemos seguir.

Então criamos o nosso próprio.

Menos de 3 semanas… porque a fundação estava certa

Distribuir tão rápido não foi sobre heroísmo ou pressão.

Foi sobre ter a fundação certa.

Tudo se baseia na API mais recente e aprimorada do Cal.com v2, que usa OAuth para autorização. Isso significou:

• fluxos de autenticação limpos

• acesso seguro

• um modelo consistente em aplicativos e extensões

• sem atalhos, sem truques

A mesma API alimenta móveis, web e extensões. Sem “endpoints apenas para extensão.” Sem “exceções para o móvel.”

Apenas uma API, projetada para escalar com o ecossistema.

👉 Se você está desenvolvendo aplicativos ou integrações no Cal.com, este é o seu ponto de partida:
https://cal.com/help/apps-and-integrations/oauth

Essa fundação OAuth é o que torna realista distribuir novos aplicativos de agendamento tão rapidamente sem comprometer a segurança ou a sanidade do desenvolvedor.

Por que isso importa (além de “olhe o que construímos”)

Distribuir para muitas plataformas só é impressionante se continuar a ser sustentável.

A verdadeira vitória não é a lista de plataformas. A verdadeira vitória é:

• Consistência: as características se implantam em todos os lugares, não “primeiro no móvel, depois na extensão”

• Velocidade: um lugar para construir, um lugar para corrigir

• Qualidade: menos divergências específicas da plataforma

• Momentum: a equipe constrói o produto em vez de código intermediário

As extensões nos permitem viver diretamente nos fluxos de trabalho. O móvel nos permite viver no mundo real. Juntos, essa área de superfície se torna uma vantagem do produto.

Créditos a quem merece

Isso não aconteceu por causa de uma única pessoa. Mas duas pessoas foram multiplicadores massivos:

• Wilson Wilson (@euboid), uma grande quantidade do suporte à extensão do navegador, casos especiais em navegadores cruzados, e “este é o truque que realmente funciona” veio de Wilson.

• Beto (@betomoedano), toneladas de experiência em Expo e ajuda prática que transforma “isto deve funcionar” em “parece bom, sente-se bem” vieram de Beto.

• e a equipe trabalhadora da call, a saber: eu, Dhairyashil Shinde, Carina Wollendorfer e

  Volnei Munhoz e Claude Code.

Obrigado a todos. Sério.

O que vem a seguir

Curiosidade: Nossos aplicativos ainda não foram lançados, o que é bastante hilário. O processo de inscrição na App Store está demorando mais do que o próprio desenvolvimento do aplicativo. Por algum motivo, ainda há questões de KYC com nossa empresa (renomeamos há alguns anos, discrepância no número D-U-N-S, funcionário não americano controlando uma empresa americana, bla bla bla.)

Às vezes eu gostaria que o desenvolvimento de aplicativos móveis pudesse experimentar o mesmo ritmo ao qual estamos acostumados na web, mas isso é muito improvável.

De qualquer forma, por favor inscreva-se na nossa lista de espera em cal.com/app e seja notificado assim que os aplicativos de produção estiverem disponíveis nas lojas. Segundo a equipa de inscrição são apenas mais alguns dias, mas as férias estão chegando, então nunca se sabe.

A base de código ainda está um pouco confusa com grandes componentes, mas estamos limpando esses agora.

No final, a parte mais empolgante é chegar ao “Cal.com em todos os lugares” com tão pouco esforço de engenharia para manter.

É que agora temos uma base onde entregar a próxima coisa parece como deveria:

• construir uma vez

• distribuir em todos os lugares

• iterar rapidamente

Essa é a meta.

E é uma meta bastante divertida de alcançar.