Ein Codebase. Fünf Plattformen. Zwei App Stores. Vier Browser.

In weniger als drei Wochen ausgeliefert.

Cal.com ging es schon immer darum, Menschen dort zu treffen, wo sie bereits sind.

Für die Terminplanung bedeutet das: überall: auf Ihrem Handy, in Ihrem Browser, in dem Tab, den Sie nie schließen, auf dem Laptop, den Sie für die Arbeit verwenden, und auf dem Gerät, das Sie greifen, wenn Sie aus der Tür rennen.

Viele von Ihnen haben danach gefragt und wir haben uns endlich entschieden, es auszuprobieren. Diese Woche kündigten wir an:

• Eine native iOS-App

• Eine native Android-App

• Eine Chrome-Erweiterung

• Eine Firefox-Erweiterung

• Eine Safari-Erweiterung

• Eine Edge-Erweiterung

Und wir haben das nicht über Monate oder Quartale getan.

Wir haben all dies in weniger als drei Wochen von der Idee bis zur Produktion ausgeliefert.

Alles ohne das Produkt in dutzende Repos zu verzweigen, die mit der Zeit langsam auseinanderdriften.

Wir haben es mit einem Codebase gemacht.

Die Kernidee: Cal.com überall ausliefern, ohne Cal.com fünfmal auszuliefern

Historisch gesehen leben „Mobile App“ und „Browsererweiterung“ in unterschiedlichen Universen.

• Mobile will React Native, native Build-Tools, App-Store-Workflows, Push-Benachrichtigungen, Deep Linking usw.

• Erweiterungen wollen Inhalts-Skripte, Hintergrund-/Service-Arbeiter, Berechtigungen, Speicher-APIs, Browser-Eigenheiten und das endlose Spiel „funktioniert in Chrome, aber…“

Der übliche Ansatz besteht darin, die Teilung zu akzeptieren:

• separate Teams

• separate Stacks

• separate Release-Prozesse

• separate Bugs

• separate UI-Inkonsistenzen

Das fühlte sich nicht nach der Art von Cal.com an.

Wir wollten, dass sich Cal überall wie dasselbe Produkt anfühlt. Gleiches UI. Dasselbe mentale Modell. Gleiche Funktionen. Gleiches Iterationstempo.

Also haben wir es so gebaut.

iOS + Android: angetrieben von den neuesten Expo und React Native

Unsere iOS- und Android-Apps werden von den neuesten Expo (expo.dev) und React Native (RN) angetrieben.

Expo hat einen Punkt erreicht, an dem Sie das Beste aus beiden Welten bekommen:

• ausgezeichnete Entwicklererfahrung

• ernsthafte Produktionsbereitschaft

• Flexibilität, wenn Sie nativ werden müssen

Am wichtigsten ist, dass Expo in eine größere These passt, die uns sehr am Herzen liegt:

Web und nativ sollten sich nicht wie separate Produkte anfühlen.

Sie sollten sich wie verschiedene Oberflächen desselben Systems anfühlen.

Erweiterungen: angetrieben von WXT

Für Browsererweiterungen haben wir auf wxt.dev aufgebaut.

Erweiterungen sind immer noch einer jener Bereiche, in denen sich Tools seltsam in der Vergangenheit festgefahren anfühlen können. WXT lässt es modern wirken:

• saubere Struktur

• vernünftige Voreinstellungen

• zuverlässige Multi-Browser-Builds

Und ja, wir haben für Chrome, Firefox, Safari und Edge gebaut.

Schon Safari allein reicht oft aus, um Teams von der Unterstützung mehrerer Browser abzuschrecken. Aber das Ziel war nie „zuerst Chrome, andere später“.

Das Ziel war Cal überall.

Der Spaßteil: Chrome-Erweiterungs-UI, angetrieben von Expo Web

Hier ist der Teil, der sich immer noch etwas surreal anfühlt:

Unsere Chrome-Erweiterungs-UI wird von Expo Web angetrieben.

Das bedeutet, dass die Erweiterungs-UI keine separate Frontend mit eigenem Komponentensystem und Styling-Abweichung ist. Es wird mit demselben UI-Ansatz gebaut, den wir bereits für Mobile verwenden und der im Web innerhalb der Erweiterungsoberfläche läuft.

Wenn ich also sage ein Codebase, meine ich es in einer Weise, die tatsächlich zählt:

• gemeinsame Bildschirme

• gemeinsame Komponenten

• gemeinsame Design-Prinzipien

• gemeinsame Logik

• gemeinsame Geschwindigkeit

Die WXT-App selbst läuft innerhalb von /extension/entrypoints/content.ts, die dann die Expo-Web-App als iFrame lädt. Dies ist der häufigste Ansatz, um „Sidebar“-Chrome-Erweiterungen zu erstellen, und diesen Trick habe ich durch Wilson Wilson (@euboid) gelernt. Leider hat das offizielle Chrome-Erweiterungs-„Popup“ eine maximale Höhe von 600px.

Wir haben sogar einige Browser-spezifische APIs eingebaut, wie zum Beispiel das Injizieren unseres Cal.com-Widgets in mail.google.com und calendar.google.com, das einfach im /extensions-Ordner von WXT erledigt werden kann.

Aus meiner Erfahrung ist diese Kombination: native iOS + Android über Expo, Multi-Browser-Erweiterungen über WXT, Erweiterungs-UI über Expo Web, alles in einem kohärenten Codebase vereint etwas, das ich persönlich so noch nirgendwo gesehen habe.

Vielleicht gibt es das irgendwo. Das Internet ist groß.

Aber ich habe es nicht gesehen, und es gab auf jeden Fall kein Handbuch, dem wir hätten folgen können.

Also haben wir unser eigenes erstellt.

Weniger als 3 Wochen… weil das Fundament richtig war

So schnell liefern war nicht wegen Heldentaten oder Überstunden.

Es ging darum, das richtige Fundament zu haben.

Alles basiert auf der neuesten Cal.com API v2, die OAuth für die Autorisierung verwendet. Das bedeutete:

• saubere Authentifizierungs-Flows

• sicherer Zugang

• ein einheitliches Modell über Apps und Erweiterungen hinweg

• keine Hacks, keine Abkürzungen

Die gleiche API unterstützt Mobile, Web und Erweiterungen. Keine „nur-Erweiterungs-Endpunkte“. Keine „nur-Mobile Ausnahmen“.

Nur eine API, die entwickelt wurde, um mit dem Ökosystem zu skalieren.

👉 Wenn Sie Apps oder Integrationen auf Cal.com aufbauen, ist dies Ihr Ausgangspunkt:
https://cal.com/help/apps-and-integrations/oauth

Dieses OAuth-Fundament ist der Grund, warum es realistisch ist, neue Terminplanungs-Apps so schnell zu liefern, ohne die Sicherheit oder den Entwicklerverstand zu gefährden.

Warum das wichtig ist (über „schau, was wir gebaut haben“ hinaus)

In viele Plattformen zu liefern, ist nur beeindruckend, wenn es wartbar bleibt.

Der eigentliche Gewinn ist nicht die Checkliste der Plattformen. Der eigentliche Gewinn ist:

• Konsistenz: Funktionen landen überall, nicht „zuerst mobil, Erweiterung später“

• Geschwindigkeit: ein Ort zum Bauen, ein Ort zum Reparieren

• Qualität: weniger plattform-spezifische Abweichungen

• Schub: das Team baut Produkt statt Kleber-Code

Erweiterungen lassen uns direkt in Workflows leben. Mobile lässt uns in der realen Welt leben. Gemeinsam wird diese Oberfläche zum Produktvorteil.

Danksagungen, wo sie hingehören

Das passierte nicht wegen einer Person. Aber zwei Menschen waren massive Multiplikatoren:

• Wilson Wilson (@euboid), eine riesige Menge der Unterstützung für Browsererweiterungen, plattformübergreifende Randfälle und „das ist der Trick, der tatsächlich funktioniert“-Wissen kam von Wilson.

• Beto (@betomoedano), viele der Expo-Expertise und praktischen Hilfen, die „das sollte funktionieren“ in „sieht gut aus, fühlt sich gut an“ verwandeln, kamen von Beto.

• und das fleißige Team bei Cal, nämlich: ich selbst, Dhairyashil Shinde, Carina Wollendorfer und

  Volnei Munhoz und Claude Code.

Danke euch allen. Ernsthaft.

Was als nächstes kommt

Fun Fact: Unsere Apps sind noch nicht live gegangen, was ziemlich lustig ist. Der Enrolment-Prozess im App Store dauert länger als die gesamte App-Entwicklung. Aus irgendeinem Grund gibt es immer noch KYC-Probleme mit unserem Unternehmen (wir haben vor ein paar Jahren umbenannt, D-U-N-S-Nummer stimmt nicht, nicht-US-Mitarbeiter leitet ein US-Unternehmen, bla bla bla.)

Manchmal wünschte ich mir, die Entwicklung mobiler Apps könnte das gleiche Tempo erleben wie wir es im Web gewohnt sind, aber das ist sehr unwahrscheinlich.

Auf jeden Fall, bitte meldet euch bei unserer Warteliste unter cal.com/app an und werdet benachrichtigt, sobald die Produktions-Apps in den Stores live gehen. Laut dem Enrolment-Team sind es nur noch ein paar Tage, aber die Feiertage stehen an, also weiß man nie.

Der Codebase ist immer noch ziemlich unordentlich mit großen Komponenten, aber wir bereinigen das jetzt.

Am Ende ist der spannendste Teil, „Cal.com überall“ mit so wenig technischem Aufwand zu erreichen.

Es ist, dass wir jetzt ein Fundament haben, bei dem sich das nächste Ding so anfühlt, wie es sich anfühlen sollte:

• einmal bauen

• überall ausliefern

• schnell iterieren

Das ist die Messlatte.

Und es ist eine ziemlich unterhaltsame Messlatte, um darüber zu springen.