Un solo codice. Cinque piattaforme. Due app store. Quattro browser.

Consegnato in meno di tre settimane.

Cal.com è sempre stato incentrato sull'incontrare le persone dove già si trovano.

Per la pianificazione, ciò significa ovunque: sul tuo telefono, nel tuo browser, nella scheda che non chiudi mai, sul laptop che usi per lavoro e sul dispositivo che prendi quando stai uscendo.

Molti di voi lo hanno richiesto e finalmente abbiamo deciso di provarci. Questa settimana abbiamo annunciato:

• Un app iOS nativa

• Un app Android nativa

• Un estensione Chrome

• Un estensione Firefox

• Un estensione Safari

• Un estensione Edge

E non l'abbiamo fatto in mesi o trimestri.

Abbiamo spedito tutto questo in meno di tre settimane dalla concezione alla produzione.

Tutto senza separare il prodotto in una dozzina di repository che lentamente divergevano nel tempo.

L'abbiamo fatto con un solo codice.

L'idea di base: spedire Cal.com ovunque senza spedire Cal.com cinque volte

Storicamente, “app mobile” e “estensione del browser” vivono in universi diversi.

• I dispositivi mobili vogliono React Native, strumenti di build nativi, flussi di lavoro del app store, notifiche push, deep linking, ecc.

• Le estensioni vogliono script di contenuto, worker di background/servizio, autorizzazioni, API di storage, peculiarità del browser e il gioco infinito del “funziona in Chrome ma…”

L'approccio usuale è accettare la divisione:

• squadre separate

• stack separati

• processi di rilascio separati

• bug separati

• incoerenze dell'interfaccia utente separate

Questo non sembrava il modo Cal.com.

Volevamo che Cal sembrasse lo stesso prodotto ovunque. Stessa UI. Stesso modello mentale. Stesse funzionalità. Stessa velocità di iterazione.

Quindi l'abbiamo costruito in quel modo.

iOS + Android: alimentato dal più recente Expo e React Native

Le nostre app iOS e Android sono alimentate da il più recente Expo (expo.dev) e React Native (RN).

Expo ha raggiunto un punto in cui ottieni il meglio di entrambi i mondi:

• eccellente esperienza per gli sviluppatori

• seria prontezza alla produzione

• flessibilità quando hai bisogno di andare nativo

La cosa più importante è che Expo si adatta a una tesi più grande a cui teniamo profondamente:

Web e nativo non dovrebbero sembrare prodotti separati.

Dovrebbero sembrare diverse superfici dello stesso sistema.

Estensioni: alimentate da WXT

Per le estensioni del browser, abbiamo costruito su wxt.dev.

Le estensioni sono ancora una di quelle aree in cui gli strumenti possono sembrare stranamente bloccati nel passato. WXT lo fa sembrare moderno:

• struttura pulita

• predefiniti sani

• build multi-browser affidabili

E sì, abbiamo costruito per Chrome, Firefox, Safari e Edge.

Safari da solo è di solito sufficiente per spaventare le squadre dal supporto multi-browser. Ma l'obiettivo non è mai stato “Chrome ora, altri più tardi.”

L'obiettivo era Cal ovunque.

La parte divertente: UI dell'estensione Chrome alimentata da Expo Web

Ecco la parte che sembra ancora leggermente surreale:

La nostra UI dell'estensione Chrome è alimentata da Expo Web.

Ciò significa che la UI dell'estensione non è un frontend separato con il proprio sistema di componenti e deriva stilistica. È costruita utilizzando lo stesso approccio UI che già usiamo per i dispositivi mobili che esegue sul web all'interno della superficie dell'estensione.

Quindi quando dico un solo codice, lo intendo in un modo che conta veramente:

• schermate condivise

• componenti condivisi

• primitivi di design condivisi

• logica condivisa

• velocità condivisa

L'app WXT stessa gira all'interno di /extension/entrypoints/content.ts che poi carica l'app expo-web come un iframe. Questo è l'approccio più comune per costruire estensioni