Met vier mensen naar beide stores opleveren
Gelijkwaardigheid tussen iOS en Android is een bezettingsbesluit vermomd als technisch besluit. Hoe een klein team beide bedient zonder te verdubbelen.
De vraag die we krijgen is welk framework we moeten gebruiken. De vraag die de uitkomst werkelijk bepaalt, is hoeveel mensen u zich twaalf maanden na lancering nog op de app kunt veroorloven.
Twee native codebases hebben twee specialisten nodig die hun platform diep kennen, en die moeten blijven. Vertrekt er één, dan staat de helft van uw product stil. In een team van vier is dat geen risico dat u kunt dragen, en het is het sterkste argument voor één gedeelde codebase.
Dus draaien wij React Native met een gedeelde TypeScript-kern, en schrijven we alleen native modules waar het platform echt verschilt — beveiligde opslag, achtergrondtaken, camerapijplijnen. Ongeveer negentig procent van de code is gedeeld, en de tien procent die dat niet is, herbergt toch al de interessante bugs.
De discipline die het laat werken is release-engineering, niet architectuur. Eén Fastlane-pijplijn, één versienummer, elke twee weken één releasetrein, gefaseerde uitrol in beide stores en een noodschakelaar voor alles wat risicovol is. Lopen de twee platformen uiteen in releaseritme, dan heeft u weer twee producten.
Bij testen nemen kleine teams een sluiproute en betalen die later. Wij houden een toestelmatrix aan met nadruk op de goedkope Android-telefoons die de gebruikers van onze klanten daadwerkelijk bezitten, en draaien de kritieke routes vóór elke release op echte hardware. Simulatoren tonen het geheugenplafond niet.
De prijs is reëel: sommige interacties voelen een fractie minder native, en soms wacht u tot het ecosysteem een nieuwe OS-functie inhaalt. Voor de meeste producten is die ruil duidelijk de moeite waard. Voor een product waarvan de hele waarde een platformfunctie is, niet — en dat zeggen we dan ook.