React Native-Entwicklungsleistungen für US & EU Mobile-, Tablet- und Embedded-Produkte

React Native ist die richtige Wahl, wenn Ihr Team bereits in TypeScript und React im Web arbeitet (enorme Code-, Design-System- und Entwickler-Wiederverwendung), wenn Over-the-Air-JS-Updates Ihren Release-Rhythmus spürbar verändern, und wenn die meiste App aus Screens-über-APIs besteht statt aus Custom-Rendering. Flutter gewinnt bei pixelgenauer plattformübergreifender UI-Parität mit Custom-Design-Systemen. Natives Swift/Kotlin gewinnt bei tiefer OS-Integration, AR/VR und plattformspezifischer Premium-UX. Kotlin Multiplatform gewinnt, wenn Geschäftslogik zwischen bestehenden nativen Teams geteilt werden soll, ohne sich auf ein UI-Framework festzulegen. Wir pflegen alle vier Praktiken und empfehlen ehrlich im Discovery-Prozess.

React Native 0.76+ ist unser Standard, und die New Architecture (Fabric + TurboModules + Bridgeless-Modus) ist seit 0.76 (Oktober 2024) standardmäßig aktiviert und 2026 produktionsreif. Wir haben New-Architecture-Apps mit über 2 Mio. MAU auf iOS und Android ausgeliefert. Hermes ist obligatorisch (Standard seit 0.70). TypeScript 5 Strict. Mindestsupportete iOS-Version: 15.1, Android API: 24. Wir pinnen die RN-Version pro Projekt, halten eine Minor-Version hinter dem neuesten Stable-Release und führen vierteljährliche Upgrades mit einem dedizierten Upgrade-Sprint durch — eine nicht mehr supportete RN-Version bleibt bei uns nie stehen.

Ja. Das Backend läuft standardmäßig in EU-Regionen (AWS eu-central-1, GCP europe-west3, Supabase eu-central-1) mit KMS-Schlüsseln im Kundenkonto. App-Store-Privacy-Manifests (seit Mai 2024 verpflichtend) werden für jede erforderliche API und SDK-Datenerfassung mit allen notwendigen Gründen ausgeliefert — React Native und gängige RN-Bibliotheken benötigen dies, und wir pflegen eine interne Kompatibilitätsmatrix. Der Play-Data-Safety-Abschnitt wird gegen das tatsächliche SDK-Inventar abgeglichen. DSGVO-Einwilligung über UMP oder ein eigenes CMP, Apple-ATT-Prompt wo IDFA benötigt wird. Für US-Verbraucherprodukte liefern wir CCPA-Hinweise mit aus.

Standardstartpunkt: Expo Prebuild (früher Bare mit Config-Plugins). Es bietet die Expo-SDK-Ergonomie (EAS Build, EAS Update, expo-router) sowie die Freiheit, native Module in Swift / Kotlin zu schreiben, ohne zu ejecten. Reines Managed-Workflow, wenn keine nativen Module benötigt werden und minimale Infrastruktur gewünscht ist (frühes MVP, interne Tools). Reines Bare, wenn von Beginn an tiefe native Integrationen nötig sind (eigene BLE-Protokolle, Hardware-SDKs, große bestehende native Codebasis). 80 % unserer Engagements 2026 starten als Prebuild.

Ja, das ist ein häufiges Engagement. Wir nutzen den offiziellen RN Upgrade Helper und die versionsweise Migrationsleitfäden als Grundlage, aber jede App ist aufgrund ihrer nativen Module einzigartig. Schritt 1: Audit jedes nativen Moduls auf New-Architecture-Kompatibilität — nicht gepflegte durch aktuelle ersetzen. Schritt 2: Schrittweises Upgrade 0.68 → 0.71 → 0.73 → 0.76 mit grünen Tests bei jedem Schritt. Schritt 3: New Architecture plattformweise hinter einem Flag aktivieren, an interne Beta ausliefern, JS-Absturzrate und ANR zwei Wochen lang überwachen. Eine typische 60k-LOC-App benötigt 2 bis 4 Monate ohne Feature-Freeze.

Dedizierte Teams beginnen bei 12.000 EUR/Monat für ein 2-Entwickler-Pod (typischerweise 1 Senior + 1 Mid plus anteiliger Tech Lead und DevOps). Standard-Mobile-Squads haben 4–6 Entwickler bei 28.000–42.000 EUR/Monat mit QA auf einer echten Gerätfarm, DevOps für Store-Releases und EAS-Pipelines sowie PM. Festpreis-Projektsprints (Discovery + MVP + App-Store- und Play-Veröffentlichung) beginnen bei 25.000 EUR. Alle Engagements beinhalten MEZ-Arbeitstag mit 9–13-Uhr-ET-Überlappung für US-Kunden, NDA + Auftragsverarbeitungsvertrag + IP-Abtretung vor Projektstart, drei Monate Mindestlaufzeit, danach monatlich kündbar mit 30 Tagen Frist.