React Native (Expo) vs. native: når to codebaser holder op med at give mening

Hvert bureau, der stadig fakturerer pr. platform, vil sige det samme: "Native er mere performant, og du har brug for native til de funktioner, du vil have." For et par år siden var det en forsvarlig position. I dag er det mest en salgsposition.

React Native — specifikt Expo på New Architecture — har lukket gabet på begge argumenter til det punkt, hvor spørgsmålet for de fleste produkt-teams er vendt. Det er ikke længere "hvorfor skal vi vælge React Native?". Det er "hvad er den konkrete grund til, at vi betaler for to teams, to release-pipelines og to af hver bug?"

Pitchet plejede at være simpelt: native kompilerer til native kode, JavaScript kører i en bro, ergo native er hurtigere. To ændringer brød det argument:

• Hermes leverer ahead-of-time bytecode og en tunet GC til React Natives workload. Cold start og hukommelse er ikke længere en pinlighed.
• JSI og New Architecture erstattede den asynkrone bro med synkrone, typede kald mellem JS og native. Serialiserings-skatten, der plejede at dominere benchmarks, er væk.

For en produkt-app — lister, formularer, navigation, netværkskald, animationer drevet på UI-tråden med Reanimated — er forskellen mellem Expo og et fuldt native byg, i reel brugertest, lille nok til, at ingen uden for engineering-teamet bemærker det.

Den anden halvdel af pitchet er, at React Native ikke kan nå platformen. Det var sandt i 2017. I 2026 er det stort set falsk, på grund af to ting:

• Expo Modules lader dig skrive et lille Swift- eller Kotlin-modul og forbruge det fra JS med typesikkerhed. Du forlader ikke Expo for at lave native arbejde; du udvider det.
• Config plugins lader det native modul ændre iOS- og Android-projekterne ved prebuild-tid, uden at du nogensinde ejecter fra managed Expo eller redigerer Info.plist / AndroidManifest.xml i hånden.

Mellem first-party Expo SDK'et og community-økosystemet er ~95 % af de native funktioner, en produkt-app har brug for, allerede pakket: kamera, filsystem, secure storage, biometri, push, baggrundsopgaver, in-app-purchases, App Clips, App Intents, Live Activities, widgets, foreground services, share extensions. De sidste 5 % kan du bygge med Expo Modules på dage, ikke uger.

Omkostningscasen for cross-platform handler sjældent om kodelinjerne. Den handler om alt det, der pakker dem ind.

• Ét team, ikke to. Én ansættelses-funnel, ét sæt konventioner, én code review-kultur. Senior-generalister bliver engagerede, fordi de ikke er låst ind i én platform.
• Ét designsystem. En token-ændring leveres til begge platforme i én PR. To codebaser betyder to fortolkninger af hver design-ændring, der driver fra hinanden hvert kvartal.
• Én udgivelseskadence. Én CI-pipeline, én OTA-kanal via EAS Update, én changelog. Native teams, der udgiver månedligt på iOS og kvartalsvis på Android, er ikke usædvanlige; brugere bemærker det.
• Én bug, ikke to rapporter. En regression i en delt komponent rettes én gang. I to codebaser er hver bug potentielt to bugs.
• Én observability-historie. Crash reporting, analyse, feature flags, A/B-testing koblet op én gang med et delt hændelses-skema.

Når teams sammenligner "Expo-udvikleromkostning" vs. "iOS + Android-udvikleromkostning" og kalder det uafgjort, tæller de som regel kun de udviklere, der skriver skærmene. Den reelle omkostning lever i den anden kopi af alt rundt om skærmene.

Der er en reel liste af tilfælde, hvor du stadig skal gå native, og en ærlig cross-platform-fortaler vil sige det:

• Spil og grafiktunge kreative værktøjer. Brug en game engine; spørgsmålet bliver Unity / Godot / native, ikke Expo vs. native.
• Pro audio- og video-apps med sub-frame latency-krav.
• AR/VR og ML-on-device, hvor du lever inde i ARKit-/ARCore-/CoreML-API'er.
• Dyb OEM-integration — CarPlay/Android Auto first-class apps, watchOS-komplikationer med rig logik, accessibility-apps der genopbygger store dele af system-UI'en.
• Meget langlivede enterprise-apps, hvor køberens indkøbsafdeling vil kræve et native byg, fordi deres RFP-skabelon siger det.

Hvis du kan svare ja til nogen af disse, er native i det mindste værd at kigge hårdt på:

• Er appen primært en realtids-grafik-, audio- eller AR-oplevelse?
• Har appen brug for en funktion, der afhænger af bleeding-edge platform-API'er inden for måneder efter OS-udgivelsen, før nogen Expo-wrapper eksisterer?
• Leverer du mindre end én udgivelse pr. kvartal og er ligeglad med iterationshastighed?
• Er der en regulatorisk eller indkøbsmæssig grund, der specifikt kræver native?

Hvis det ærlige svar på alle fire er nej — tilfældet for det overvældende flertal af startup-, scale-up- og produkt-apps — betaler du for to codebaser af vane, ikke teknisk nødvendighed.