Über diesen Eintrag
Leistungsumfang
Eine einzige React-Native-Codebasis, die eine stimmige mobile App für beide Stores hervorbringt und Navigation, Anmeldung, Push-Benachrichtigungen, Offline-Unterstützung sowie das plattformspezifische Verhalten abdeckt, das plattformübergreifende Werkzeuge nicht automatisch regeln.
Unsere Methode
Die Entwicklung beginnt an Ihrer tatsächlichen API statt an Platzhalterdaten, da sich echte Endpunkte anders verhalten als Mocks. Die Anmeldung setzt auf sichere geräteseitige Speicherung mit zentralisierter Aktualisierungslogik an einer Stelle, da eine verstreute Token-Handhabung der Bereich ist, an dem mobile Apps typischerweise Fehler entwickeln. Listen werden virtualisiert und seitenweise geladen; Bilder werden zwischengespeichert und passend zum Gerät skaliert, anstatt in voller Größe abgerufen zu werden.
Plattformspezifische Anforderungen werden als vollwertige Lieferbestandteile statt als nachträgliche Gedanken behandelt: iOS erfordert eigene Berechtigungsformulierungen und Bereitstellungsprofile, Android benötigt Benachrichtigungskanäle und eine sinnvolle Handhabung der Zurück-Taste, und Deep Links müssen auf beiden Plattformen auch nach einem Kaltstart weiterhin funktionieren.
Was Sie erhalten
- Ein TypeScript-React-Native-Projekt, das nur die nativen Module enthält, die Sie tatsächlich benötigen.
- Testversionen sowohl auf dem iOS-Betakanal als auch auf dem internen Test-Track von Android, damit Sie sie frühzeitig ausprobieren können.
- Vollständig angebundene Push-Benachrichtigungen, einschließlich des serverseitigen Auslösers.
- Release-Builds sowie Store-Eintragstexte, Screenshots und Einreichungshinweise.
- Eine kurze Einführung, damit Sie die App anschließend selbst erstellen, ausführen und veröffentlichen können.
Was wir von Ihnen benötigen
Eine API oder zumindest eine Spezifikation dafür, die Handvoll Bildschirme, auf die es am meisten ankommt, sowie Entwicklerkonten bei Apple und Google, falls Sie diese bereits besitzen. Falls nicht, legen wir genau dar, was wann erforderlich ist.
Umfangsgrenzen
Dies deckt eine App für eine Zielgruppe ab. Wenn ein Produkt zwei verschiedene Nutzererfahrungen erfordert, beispielsweise eine kundenorientierte App und eine separate Fahrer-App, zählt dies als zwei separate Builds, und wir weisen vor der Angebotserstellung darauf hin statt im Nachhinein.
Tempo und Aktualisierungen
Eine frühe Testversion ist in der Regel weit vor dem Ende des Projekts fertig, sodass Feedback zur laufenden App statt anhand statischer Screenshots gegeben wird. Die Veröffentlichungs-Checkliste bleibt durchgehend eindeutig und umfasst Berechtigungen, Deep Links, Offline-Verhalten und Store-Metadaten, da dies meist die Punkte sind, die aus einem funktionierenden Build eine abgelehnte Einreichung machen.