Ich werde eine plattformübergreifende mobile App mit React Native für iOS und Android entwickeln

Was dies abdeckt

Eine React Native Codebasis, zwei Stores, ein Satz von Fehlern, die behoben werden müssen. Navigation, Authentifizierung, Push-Benachrichtigungen, Offline-Verwaltung und die Plattformunterschiede, die ein plattformübergreifendes Framework nicht von selbst verschwinden lässt.

Wie ich es angehe

Die App wird vom ersten Tag an gegen Ihre echte API erstellt, nicht gegen simulierte Daten, die sich besser verhalten als die Produktion jemals wird. Die Authentifizierung verwendet sicheren Speicher auf dem Gerät und Aktualisierungstoken, die an einem Ort verwaltet werden, da über Bildschirme verstreute Token-Fehler die häufigste Ursache für das Verrotten mobiler Apps sind. Listen sind virtualisiert und paginiert; Bilder werden für das Gerät zwischengespeichert und dimensioniert, anstatt in voller Auflösung heruntergeladen zu werden.

Plattformarbeit wird als Arbeit behandelt, nicht als Fußnote: iOS benötigt seine eigenen Berechtigungszeichenfolgen und Bereitstellung, Android benötigt seine Benachrichtigungskanäle und das Verhalten der Zurück-Taste, und beide benötigen Deep Links, die einen Kaltstart überleben.

Lieferumfang

• React Native Projekt in TypeScript, mit den nativen Modulen, die Sie benötigen und keinen anderen.
• TestFlight- und Play-interne Builds, damit Sie es frühzeitig in den Händen halten können.
• Push-Benachrichtigungen End-to-End verdrahtet, einschließlich des Backend-Triggers.
• Release-Builds, Store-Eintragstext und Screenshots sowie die für die Einreichung erforderlichen Notizen.
• Eine kurze Anleitung zum selbstständigen Ausführen, Erstellen und Veröffentlichen.

Was ich brauche

Eine API oder eine Spezifikation dafür, die drei wichtigsten Bildschirme und Apple- und Google-Entwicklerkonten, falls Sie diese bereits haben. Falls nicht, werde ich Ihnen genau sagen, was wann zu erstellen ist.

Umfanghinweis

Eine App, ein Publikum. Wenn das Produkt zwei sehr unterschiedliche Erfahrungen benötigt – zum Beispiel eine Kunden-App und eine Fahrer-App – sind das zwei Builds, und ich werde dies vor der Angebotserstellung und nicht danach mitteilen.

Bearbeitungszeit und Kommunikation

Der erste TestFlight- oder interne Build ist in der Regel innerhalb von zwei Wochen verfügbar, sodass Sie die App in den Händen halten und Feedback zum Produkt selbst geben können, anstatt zu Screenshots. Ich halte die Release-Checkliste explizit – Berechtigungen, Deep Links, Offline-Verhalten, Store-Metadaten –, da dies die Punkte sind, die eine funktionierende App in eine abgelehnte Einreichung verwandeln. Jeder Build, den Sie erhalten, ist ein Build, den Sie veröffentlichen könnten.