Un seul codebase. Cinq plateformes. Deux magasins d'applications. Quatre navigateurs.

Expédié en moins de trois semaines.

Cal.com a toujours consisté à rencontrer les gens là où ils sont déjà.

Pour la planification, cela signifie partout : sur votre téléphone, dans votre navigateur, dans l'onglet que vous ne fermez jamais, sur l'ordinateur portable que vous utilisez pour le travail, et sur l'appareil que vous prenez quand vous sortez en courant par la porte.

Beaucoup d'entre vous l'ont demandé et nous avons finalement décidé d'essayer. Cette semaine, nous avons annoncé :

• Une application native iOS

• Une application native Android

• Une extension Chrome

• Une extension Firefox

• Une extension Safari

• Une extension Edge

Et nous n'avons pas fait ça sur des mois ou des trimestres.

Nous avons expédié tout cela en moins de trois semaines de l'idée à la production.

Le tout sans forker le produit en une douzaine de repos qui se séparent lentement avec le temps.

Nous l'avons fait avec un seul codebase.

L'idée centrale : livrer Cal.com partout sans expédier Cal.com cinq fois

Historiquement, « application mobile » et « extension de navigateur » vivent dans des univers différents.

• Les mobiles veulent React Native, des outils de construction native, des workflows d'app store, des notifications push, des liens profonds, etc.

• Les extensions veulent des scripts de contenu, des travailleurs en arrière-plan/service, des permissions, des API de stockage, des particularités de navigateur, et le jeu sans fin « fonctionne dans Chrome mais... ».

L'approche habituelle est d'accepter la séparation :

• équipes distinctes

• stacks distincts

• processus de publication distincts

• bogues distincts

• incohérences d'UI distinctes

Cela ne semblait pas être la façon Cal.com.

Nous voulions que Cal se sente comme le même produit partout. Même UI. Même modèle mental. Même fonctionnalités. Même vitesse d'itération.

Alors nous l'avons construit comme ça.

iOS + Android : propulsé par les dernières versions d'Expo et de React Native

Nos applications iOS et Android sont propulsées par les dernières versions d'Expo (expo.dev) et de React Native (RN).

Expo a atteint un point où vous obtenez le meilleur des deux mondes :

• excellente expérience développeur

• préparation sérieuse pour la production

• flexibilité quand vous avez besoin de passer au natif

Le plus important, Expo s'inscrit dans une thèse plus grande à laquelle nous tenons profondément :

Web et natif ne devraient pas se sentir comme des produits distincts.

Ils devraient se sentir comme des surfaces différentes du même système.

Extensions : propulsées par WXT

Pour les extensions de navigateur, nous avons construit sur wxt.dev.

Les extensions sont toujours l'un de ces domaines où les outils peuvent sembler étrangement bloqués dans le passé. WXT le rend moderne :

• structure propre

• défauts sensés

• constructions multi-navigateurs fiables

Et oui, nous avons construit pour Chrome, Firefox, Safari, et Edge.

Safari seul suffit généralement à effrayer les équipes quant au support multi-navigateurs. Mais l'objectif n'a jamais été « Chrome maintenant, les autres plus tard ».

L'objectif était Cal partout.

La partie amusante : UI de l'extension Chrome propulsée par Expo Web

Voici la partie qui semble encore légèrement surréaliste :

Notre UI de l'extension Chrome est propulsée par Expo Web.

Cela signifie que l'UI de l'extension n'est pas une interface utilisateur distincte avec son propre système de composants et de style. Elle est construite en utilisant la même approche UI que nous utilisons déjà pour le mobile tournant sur le web à l'intérieur de la surface de l'extension.

Donc, quand je dis un seul codebase, je le dis de manière à ce que cela compte vraiment :

• écrans partagés

• composants partagés

• primitives de conception partagées

• logique partagée

• vitesse partagée

L'application WXT elle-même s'exécute dans /extension/entrypoints/content.ts qui charge ensuite l'application expo-web comme un iframe. C'est l'approche la plus courante pour construire des extensions Chrome de type "sidebar" et j'ai appris ce truc par Wilson Wilson (@euboid). Malheureusement, le "popup" officiel des extensions Chrome a une hauteur maximale de 600px.

Nous avons même saupoudré quelques API uniquement pour les navigateurs comme l'injection de notre widget Cal.com dans mail.google.com et calendar.google.com, ce qui peut facilement être fait dans le dossier /extensions de WXT.

D'après mon expérience, cette combinaison : iOS + Android natif via Expo, extensions multi-navigateurs via WXT, UI d'extension via Expo Web, le tout lié ensemble dans un codebase cohérent est quelque chose que je n'ai personnellement jamais vu fait comme ça avant.

Peut-être que cela existe quelque part. Internet est grand.

Mais je ne l'ai pas vu, et il n'y avait certainement pas de livre de jeu que nous pouvions suivre.

Alors nous avons fait le nôtre.

Moins de 3 semaines… parce que la fondation était la bonne

Expédier aussi rapidement n'était pas une question d'héroïsme ou de crunch.

C'était à propos d'avoir la bonne fondation.

Tout repose sur l'API v2 Cal.com la plus récente et la meilleure, qui utilise OAuth pour l'autorisation. Cela signifiait :

• flux d'authentification propres

• accès sécurisé

• un modèle cohérent à travers les applications et les extensions

• pas de hacks, pas de raccourcis

La même API alimente mobile, le web et les extensions. Pas de « points de terminaison uniquement pour extensions ». Pas d'« exceptions mobiles ».

Juste une API, conçue pour évoluer avec l'écosystème.

👉 Si vous construisez des applications ou des intégrations sur Cal.com, c'est votre point de départ :
https://cal.com/help/apps-and-integrations/oauth

Cette fondation OAuth est ce qui rend réaliste d'expédier de nouvelles applications de planification si rapidement sans compromettre la sécurité ou la santé mentale des développeurs.

Pourquoi ça importe (au-delà de "regardez ce que nous avons construit")

Expédier sur de nombreuses plateformes n'est impressionnant que si cela reste maintenable.

La vraie victoire n'est pas la liste des plateformes. La vraie victoire est :

• Consistance : les fonctionnalités arrivent partout, pas « mobile d'abord, extension plus tard »

• Vitesse : un endroit pour construire, un endroit pour réparer

• Qualité : moins de divergences spécifiques à la plateforme

• Momentum : l'équipe construit le produit au lieu du code colle

Les extensions nous permettent de vivre directement dans les workflows. Les mobiles nous permettent de vivre dans le monde réel. Ensemble, cette surface devient un avantage produit.

Des crédits où ils sont dus

Cela ne s'est pas produit grâce à une seule personne. Mais deux personnes ont été des multiplicateurs massifs :

• Wilson Wilson (@euboid), une énorme quantité de soutien aux extensions de navigateur, de cas particuliers multi-navigateurs, et de « c'est l'astuce qui fonctionne vraiment » a été fournie par Wilson.

• Beto (@betomoedano), beaucoup de l'expertise Expo et de l'aide pratique qui transforme « ça devrait fonctionner » en « ça a l'air bien, ça donne une bonne impression » est venu de Beto.

• et l'équipe travailleuse de Cal à savoir : moi-même, Dhairyashil Shinde, Carina Wollendorfer et

  Volnei Munhoz et Claude Code.

Merci à vous tous. Sérieusement.

Que se passerait-il ensuite?

Fait amusant : Nos applications ne sont pas encore en ligne, ce qui est assez hilarant. Le processus d'inscription à l'App Store prend plus de temps que tout le développement de l'application lui-même. Pour une raison quelconque, il y a encore des problèmes KYC avec notre entreprise (nous avons changé de nom il y a quelques années, erreur de numéro D-U-N-S, employé non américain contrôlant une entreprise américaine, bla bla bla.)

Parfois, j'aimerais que le développement d'applications mobiles puisse connaître le même rythme que nous avons sur le web, mais c'est très improbable.

Quoi qu'il en soit, s'il vouuuuus plaît inscrivez-vous à notre liste d'attente sur cal.com/app et soyez informé lorsque les applications de production seront en ligne dans les magasins. Selon l'équipe d'inscription, cela ne prend que quelques jours de plus, mais les vacances approchent donc vous ne savez jamais.

Le codebase est encore assez désordonné avec de gros composants mais nous les nettoyons maintenant.

En fin de compte, la partie la plus excitante est d'amener « Cal.com partout » avec si peu de frais généraux d'ingénierie pour le maintenir.

C'est maintenant que nous avons une fondation où expédier la prochaine chose se sent comme ça devrait :

• le construire une fois

• expédiez-le partout

• itérer rapidement

C'est la barre.

Et c'est une barre assez amusante à franchir.