Worum es bei der Wahl tatsächlich geht
Eine native App wird in der eigenen Sprache und dem eigenen Toolkit jeder Plattform geschrieben: Swift für iOS, Kotlin für Android. Zwei Plattformen heißt zwei Codebasen, meist von zwei Gruppen Fachleuten gebaut. Mit React Native schreibt ein Team eine App in JavaScript oder TypeScript mit React; die eigene Beschreibung lautet „written in JavaScript, rendered with native code“, also in JavaScript geschrieben und mit nativem Code dargestellt, mit Komponenten, die den nativen Bausteinen jeder Plattform entsprechen [1]. Die Seiten sind echte native Seiten, keine Webseite in einer Hülle.
Das ist keine Nischenwahl. Die Website von React Native nennt Apps von Meta, Microsoft (darunter Office, Outlook und Teams), Shopify und Discord unter denen, die damit gebaut sind [1]. Flutter ist die andere gängige plattformübergreifende Option, mit ähnlichen Abwägungen und einem eigenen Ansatz zur Darstellung; das meiste, was folgt, gilt auch dafür.
Wo React Native die bessere Wahl ist
- Business-Apps aus Formularen, Listen, Dashboards, Buchungen, Zahlungen, Nachrichten und Benachrichtigungen. Das sind die meisten Apps.
- Produkte, die auch eine Web-App haben. React-Kenntnisse und mancher Code wie Datenmodelle und Validierung werden mit dem Web geteilt.
- Teams, die eine Codebasis pflegen wollen, einen Satz Tests und Funktionen, die auf beiden Plattformen gleichzeitig ankommen.
- Projekte, bei denen es wichtiger ist, mit einem Budget in beide Stores zu kommen, als das letzte bisschen Plattformschliff herauszuholen.
Braucht eine React-Native-App etwas, das das Framework nicht bietet, etwa ein bestimmtes Bluetooth-Gerät oder ein plattformspezifisches Widget, wird für dieses Stück ein natives Modul in Swift oder Kotlin geschrieben. Der Rest der App bleibt geteilt.
Wir beginnen React-Native-Projekte meist mit Expo, einem Open-Source-Toolkit rund um React Native, das Builds, Store-Einreichungen und Updates übernimmt, und ergänzen native Module nur, wo eine Funktion sie braucht. Das hält das Projekt nah am Standardweg, was Upgrades leichter macht und den Code leichter von einem anderen Team übernehmen lässt.
Wo nativ seinen Mehraufwand wert ist
- Aufwendige Grafik, Kamera- oder Audioverarbeitung in Echtzeit, Augmented Reality und Spiele, wo jedes Bild zählt.
- Tiefe Plattformintegration: Widgets, Watch-Apps, Fahrzeugdisplays, Hintergrundverarbeitung mit strengen Grenzen oder neue Plattformfunktionen am Tag ihrer Veröffentlichung.
- Apps, die immer nur eine Plattform brauchen, etwa eine interne iPad-App für ein Team, das nur iPads nutzt.
- Organisationen, die schon starke iOS- und Android-Teams haben und das Budget, beide auszulasten.
Nebeneinander
| React Native | Nativ (Swift und Kotlin) | |
|---|---|---|
| Codebasen | Eine, mit kleinen nativen Modulen, wo nötig | Zwei, eine je Plattform |
| Aussehen und Bedienung | Native Komponenten; bei Business-Apps sehr nah an nativ | Genau nativ, mit jedem Plattformdetail verfügbar |
| Leistung | Gut für typische Apps; aufwendige Grafik braucht Sorgfalt oder native Module | Bestmöglich, mit direktem Zugriff auf jede Plattform-API |
| Neue Plattformfunktionen | Meist mit Verzögerung verfügbar oder über ein natives Modul | Am Tag der Veröffentlichung verfügbar |
| Mit einer Web-App geteilt | Kenntnisse und mancher Code wie Validierung und Datentypen | Wenig oder nichts |
| Team | Ingenieure für React und TypeScript, dazu etwas natives Wissen | Fachleute für iOS und Android |
| Wartung | Ein Satz Funktionen und Tests; Framework-Upgrades, die eingeplant werden müssen | Zwei Sätze Funktionen und Tests, die im Gleichschritt bleiben müssen |
Was die App-Stores so oder so verlangen
Den Stores ist egal, wie eine App gebaut ist, aber sie setzen Regeln, die jedes mobile Projekt und seinen Kalender prägen.
- Die Prüfung braucht Zeit. Apple gibt an, dass im Schnitt 90 % der Einreichungen in weniger als 24 Stunden geprüft werden [2], aber eine Ablehnung bedeutet eine Korrektur und eine weitere Prüfung, also planen Sie Starts mit Puffer.
- Die Richtlinien von Apple sagen, eine App sollte Funktionen, Inhalte und eine Oberfläche bieten, die sie über eine neu verpackte Website hinausheben [3]. Eine Webseite in einer App-Hülle wird wahrscheinlich abgelehnt.
- Die Richtlinie 2.5.2 von Apple sagt, dass Apps keinen Code herunterladen oder ausführen dürfen, der Funktionen einführt oder ändert [3]. React-Native-Apps können manche Updates drahtlos verteilen, aber neue Funktionen gehören in ein geprüftes Release.
- Google Play verlangt, dass neue Apps und Updates auf eine aktuelle Android-Version zielen: ab dem 31. August 2026 für die meisten Apps Android 16, API-Level 36 [4]. Die Anforderung steigt mit Android, also braucht jede App regelmäßige Upgrades, um weiter Updates ausliefern zu können.
Dieser letzte Punkt ist ein laufender Kostenpunkt jeder mobilen App, nativ oder nicht. Plattform-Upgrades, neue Gerätegrößen und Änderungen der Store-Richtlinien kommen jedes Jahr, also planen Sie Wartung von Anfang an ein.
Wann Sie keines von beidem brauchen
Manche Apps müssen gar nicht in einen Store. Eine responsive Web-App funktioniert auf jedem Telefon, lässt sich auf den Startbildschirm legen und aktualisiert sich in dem Moment, in dem Sie ausliefern, ohne Prüfung. Besuchen Ihre Nutzer Sie gelegentlich, finden Sie über Suche oder Links und brauchen keine Offline-Nutzung, keinen Standort im Hintergrund und keine umfangreichen Benachrichtigungen, beginnen Sie im Web.
- Gut passend fürs Web: Kundenportale, Buchen und Bestellen, Dashboards, interne Werkzeuge, die am Schreibtisch wie unterwegs genutzt werden.
- Gut passend für eine Store-App: Produkte für den täglichen Gebrauch, Offline-Arbeit im Außendienst, Kamera- und Sensorfunktionen, zuverlässige Push-Benachrichtigungen und alles, was Nutzer in einem Store erwarten.
- Ein häufiger Weg: die Web-App starten, lernen, was Menschen auf ihren Telefonen nutzen, und dann die mobile App für diese Abläufe bauen.
Im Web zu beginnen ist keine verschwendete Arbeit. Backend, Verwaltungsbereich, Datenmodell und viel vom Design gehen direkt in die mobile App über, also kostet der zweite Schritt weniger, als dort zu beginnen gekostet hätte.
Die Hälfte einer mobilen App, die niemand sieht
Wie auch immer die Seiten gebaut werden, ein großer Teil eines mobilen Projekts ist darunter dieselbe Arbeit, und oft der größere Teil.
- Das Backend: Server, Datenbank und APIs, mit denen die App spricht, mit Anmeldung, Berechtigungen und einem Verwaltungsbereich für Mitarbeitende. Nativ oder React Native, das wird geteilt.
- Offline und Synchronisierung: Nutzen Menschen die App dort, wo der Empfang schlecht ist, muss sie Arbeit auf dem Telefon speichern und später abgleichen, ohne etwas zu verlieren oder zu verdoppeln. Das ist so sehr Designarbeit wie Code.
- Push-Benachrichtigungen: Zertifikate und Schlüssel für Apple und Google, ein Dienst zum Senden und Einstellungen, mit denen Nutzer steuern, was sie erhalten.
- Tests auf echten Geräten: verschiedene Bildschirmgrößen, ältere Betriebssystemversionen, langsame Netze und unterbrochene Sitzungen. Automatisierte Tests decken die Logik ab; Menschen mit echten Telefonen den Rest.
- Release-Management: Store-Einträge, Screenshots, Datenschutzangaben, gestaffelte Ausrollungen, Absturzberichte und ein Weg zurück.
Ein Angebot, das die Seiten berechnet, aber nicht diese Hälfte, wird sich verschieben. Bitten Sie darum, dass sie aufgeführt wird.
Zwei mobile Projekte, nach unserer Preisliste berechnet
Die durchgerechneten Beispiele unten zeigen die Spanne nach unserer heutigen Preisliste, mit den Stunden je Rolle und dem Zahlungsplan. Das erste ist eine iPhone-App für sich. Das zweite umfasst iOS und Android mit einer Web-App und einem Verwaltungsbereich. Wählen Sie statt einer geteilten Codebasis zwei getrennte native Apps, wird der Großteil der mobilen Arbeit zweimal gemacht; öffnen Sie eines der Beispiele im Rechner, und wir berechnen diese Variante mit Ihnen.
Durchgerechnetes Beispiel, jetzt berechnet
Eine iPhone-App
Sechzehn Seiten auf iOS mit Anmeldung, In-App-Zahlungen, Push-Benachrichtigungen und Analytics, mit individuellem Design und personenbezogenen Daten.
- Entwicklung
- ≈ 57.200 USD bis 87.400 USD, delivered within 26 weeksCAD 81,400 to 124,400
Preise in Ihrer Währung sind Schätzungen zum heutigen Kurs der Bank of Canada. Alle Rechnungen werden in CAD oder USD gestellt.
Geschätzter Aufwand nach Rolle
- Développement
- 318 to 486 h
- Concepteur de produits
- 57 to 87 h
- Ingénieur assurance qualité
- 39 to 59 h
- Développeur dorsal principal
- 38 to 59 h
- Concepteur de produits principal
- 38 to 58 h
- Gestionnaire de projet
- 37 to 57 h
- Développeur dorsal
- 35 to 54 h
- Développeur frontal
- 32 to 49 h
- Développeur mobile
- 25 to 39 h
- Ingénieur principal
- 24 to 36 h
- Architecte logiciel
- 21 to 32 h
- Développeur mobile principal
- 20 to 30 h
- Développeur frontal principal
- 19 to 29 h
- Développeur dorsal junior
- 18 to 27 h
- Développeur frontal junior
- 13 to 19 h
- Développeur mobile junior
- 11 to 17 h
- Rédacteur technique
- 7 to 10 h
- Ingénieur DevOps
- 6 to 10 h
Wie bezahlt wird
- Anzahlung 20%
- CAD 16,280 to 24,880
- Découverte 10%
- CAD 8,140 to 12,440
- Maquettes approuvées 10%
- CAD 8,140 to 12,440
- Première version sur appareils 30%
- CAD 24,420 to 37,320
- Soumission aux boutiques 10%
- CAD 8,140 to 12,440
- Mise en ligne 10%
- CAD 8,140 to 12,440
- Holdback, 30 days after launch (10%)
- CAD 8,140 to 12,440
Durchgerechnetes Beispiel, jetzt berechnet
Apps für iOS und Android mit einer Web-App
Zweiundzwanzig Seiten über iOS, Android und das Web, mit Anmeldung, Zahlungen, einem Verwaltungsbereich für Mitarbeitende, Benachrichtigungen und Analytics und einem Supportplan nach dem Start.
- Entwicklung
- ≈ 97.600 USD bis 149.000 USD, delivered within 25 weeksCAD 139,000 to 212,600
Preise in Ihrer Währung sind Schätzungen zum heutigen Kurs der Bank of Canada. Alle Rechnungen werden in CAD oder USD gestellt.
Geschätzter Aufwand nach Rolle
- Développement
- 528 to 807 h
- Concepteur de produits
- 107 to 164 h
- Concepteur de produits principal
- 71 to 109 h
- Gestionnaire de projet
- 68 to 104 h
- Développeur frontal
- 64 to 98 h
- Développeur dorsal principal
- 63 to 96 h
- Ingénieur assurance qualité
- 61 to 93 h
- Développeur dorsal
- 57 to 88 h
- Ingénieur principal
- 40 to 61 h
- Développeur frontal principal
- 38 to 59 h
- Développeur mobile
- 34 to 52 h
- Architecte logiciel
- 34 to 52 h
- Développeur dorsal junior
- 29 to 44 h
- Développeur mobile principal
- 27 to 41 h
- Développeur frontal junior
- 26 to 39 h
- Développeur mobile junior
- 15 to 23 h
- Ingénieur DevOps
- 13 to 20 h
- Rédacteur technique
- 11 to 16 h
Wie bezahlt wird
- Anzahlung 20%
- CAD 27,800 to 42,520
- Découverte 9.2%
- CAD 12,788.00 to 19,559.20
- Maquettes approuvées 9.2%
- CAD 12,788.00 to 19,559.20
- Fonctions principales 7.6%
- CAD 10,564.00 to 16,157.60
- Développement complet 5%
- CAD 6,950 to 10,630
- Première version sur appareils 20.1%
- CAD 27,939.00 to 42,732.60
- Tests et corrections 2.5%
- CAD 3,475 to 5,315
- Soumission aux boutiques 6.7%
- CAD 9,313.00 to 14,244.20
- Mise en ligne 9.7%
- CAD 13,483.00 to 20,622.20
- Holdback, 30 days after launch (10%)
- CAD 13,900 to 21,260
Nach dem Start, so oder so
Eine mobile App ist nie so fertig, wie es eine Website sein kann. Jedes Jahr bringt neue Betriebssystemversionen, neue Geräte und neue Store-Regeln, und Nutzer erwarten, dass die App mithält. Planen Sie einen Release-Rhythmus, monatlich oder vierteljährlich, der kleine Verbesserungen mit den Upgrades bündelt, die die Plattformen verlangen, und lassen Sie Absturzberichte und Analytics laufen, damit Sie wissen, welche Probleme zählen. Bei React Native kommen Framework-Upgrades auf diese Liste; bei nativen Apps machen Sie alles zweimal.
Wie Sie entscheiden
- 01
Listen Sie die Funktionen auf, die das Gerät nutzen
Kamera, Standort, Bluetooth, Hintergrundarbeit, Widgets, Gesundheitsdaten. Jede ist eine Frage nach nativer Unterstützung.
- 02
Fragen Sie, ob eine davon erstklassig sein muss
Ist eine Funktion das Produkt, etwa ein Kameraeffekt in Echtzeit, kann sie nativen Code für diese Funktion oder die ganze App rechtfertigen.
- 03
Prüfen Sie Ihre Plattformen
Sind Ihre Nutzer auf iOS und Android, ist eine geteilte Codebasis der Normalfall. Sind alle auf einer, ist nativ für diese eine vernünftig.
- 04
Denken Sie an das Web
Brauchen Sie auch eine Web-App, teilt React Native Kenntnisse und manchen Code mit ihr.
- 05
Planen Sie die Jahre nach dem Start
Wer wird sie pflegen, und können Sie dafür einstellen? Ingenieure für React und TypeScript sind leichter zu finden als zwei native Fachleute.