Mit vier Leuten in beide Stores ausliefern
Gleichstand zwischen iOS und Android ist eine Personalentscheidung im technischen Gewand. Wie ein kleines Team beide bedient, ohne sich zu verdoppeln.
Gefragt werden wir, welches Framework man nehmen soll. Die Frage, die das Ergebnis tatsächlich bestimmt, lautet: Wie viele Personen können Sie sich zwölf Monate nach dem Start noch für die App leisten?
Zwei native Codebasen brauchen zwei Fachleute, die ihre jeweilige Plattform tief kennen — und sie müssen bleiben. Geht eine, steht das halbe Produkt still. In einem Team von vier ist das kein tragbares Risiko, und es ist das stärkste Argument für eine gemeinsame Codebasis.
Also fahren wir React Native mit einem gemeinsamen TypeScript-Kern und schreiben native Module nur dort, wo sich die Plattformen wirklich unterscheiden — sichere Speicherung, Hintergrundaufgaben, Kamerapipelines. Etwa neunzig Prozent des Codes sind geteilt, und die zehn Prozent, die es nicht sind, beherbergen ohnehin die interessanten Fehler.
Was es tragfähig macht, ist Release-Engineering, nicht Architektur. Eine Fastlane-Pipeline, eine Versionsnummer, alle zwei Wochen ein Release-Zug, gestufter Rollout in beiden Stores und ein Notschalter für alles Riskante. Driften die Plattformen auf unterschiedliche Takte, haben Sie wieder zwei Produkte.
Beim Testen mogeln kleine Teams und zahlen später dafür. Wir halten eine Gerätematrix mit Schwerpunkt auf den günstigen Android-Geräten, die die Nutzer unserer Kunden tatsächlich besitzen, und fahren die kritischen Wege vor jedem Release auf echter Hardware. Simulatoren zeigen die Speichergrenze nicht.
Der Preis ist real: Manche Interaktionen fühlen sich eine Spur weniger nativ an, und gelegentlich warten Sie, bis das Ökosystem eine neue Betriebssystemfunktion nachzieht. Für die meisten Produkte lohnt sich der Tausch offensichtlich. Für ein Produkt, dessen ganzer Wert in einer Plattformfähigkeit liegt, nicht — und das sagen wir dann auch.