React Native oder nativ: wie wir entscheiden
Die Framework-Debatte ist meist die falsche Debatte. Es zählt, ob das Produkt Plattformtiefe braucht — und wer es in einem Jahr pflegt.
Fast jedes Mobile-Gespräch beginnt mit einer Framework-Frage, und fast keines sollte das. Die Entscheidung folgt aus zwei Dingen: wie stark das Produkt von Plattformfähigkeiten abhängt und wie viele Menschen es in zwölf Monaten pflegen werden.
Für rund drei Viertel der Produkte greifen wir zu React Native. Der Grund ist die Ökonomie des Gleichstands — eine Codebasis heißt, dass iOS und Android dieselbe Funktion am selben Tag ausliefern, und ein Team von vier kann das tragen. Zwei native Codebasen heißen zwei Fachleute und ein dauerhaftes Risiko, dass eine davon geht.
Nativ gehen wir, wenn der Wert des Produkts in einer Plattformfähigkeit liegt. Dauerhafte Hintergrundverarbeitung, schwere Medienpipelines, komplexe Kamera- oder Sensorarbeit, tiefe Widget- und Watch-Integration. Dann ist nicht die Brücke das Problem, sondern dass Sie das ganze Projekt um Zugang zu genau dem kämpfen, worum es geht.
Das Performance-Argument ist weitgehend erledigt und wird weitgehend missbraucht. Mit der neuen Architektur und Hermes sind Listen-Scrolling und Animation nah genug dran, dass Nutzende es nicht merken. Was Nutzende merken, ist die Kaltstartzeit, und die ist eine Ingenieursdisziplin, keine Eigenschaft des Frameworks.
Die Frage, die wir Kunden tatsächlich stellen, lautet: Wird diese App in einem Jahr von einem Mobile-Team gepflegt oder von Ihren bestehenden Web-Entwicklern mit Unterstützung? Ist es Letzteres, ist eine gemeinsame TypeScript-Codebasis kein Kompromiss, sondern die einzige Variante, die überlebt.