Keresztplatformos mobilalkalmazást építek React Native-vel iOS-re és Androidra

Amit ez tartalmaz

Egy React Native kódbázis, két áruház, egy hibakészlet javításra. Navigáció, hitelesítés, push értesítések, offline kezelés és a platformkülönbségek, amelyeket egy keresztplatformos keretrendszer önmagában nem tüntet el.

Hogyan közelítem meg

Az alkalmazás az első naptól kezdve a valós API-hoz épül, nem pedig olyan mock adatokhoz, amelyek jobban viselkednek, mint a valós termelés. A hitelesítés biztonságos tárolást használ az eszközön és frissítési tokeneket kezel egy helyen, mert a képernyőkön szétszórt tokenhibák a leggyakoribb módja annak, hogy a mobilalkalmazások elromlanak. A listák virtualizáltak és lapozottak; a képek gyorsítótárazottak és az eszközhöz méretezettek, nem pedig teljes felbontásban letöltöttek.

A platformspecifikus munka munkának számít, nem lábjegyzetnek: az iOS-nek saját engedélyezési stringekre és provisioningra van szüksége, az Androidnak saját értesítési csatornákra és visszagomb viselkedésre, és mindkettőnek szüksége van mélylinkekre, amelyek hidegindítás után is működnek.

Szállítmányok

• React Native projekt TypeScriptben, a szükséges natív modulokkal és semmi mással.
• TestFlight és Play belső tesztelési verziók, hogy korán a kezében tarthassa.
• Végponttól végpontig bekötött push értesítések, beleértve a backend triggert is.
• Kiadási verziók, áruházi leírás és képernyőképek, valamint a beküldéshez szükséges jegyzetek.
• Rövid útmutató az önálló futtatáshoz, építéshez és kiadáshoz.

Amire szükségem van

Egy API vagy annak specifikációja, a három legfontosabb képernyő, valamint Apple és Google fejlesztői fiókok, ha már rendelkezik ilyenekkel. Ha nem, pontosan megmondom, mit és mikor kell létrehoznia.

Projekt megjegyzés

Egy alkalmazás, egy közönség. Ha a terméknek két nagyon eltérő élményre van szüksége – például egy ügyfélalkalmazás és egy sofőralkalmazás –, akkor azok két buildet jelentenek, és ezt az árajánlat előtt, nem pedig utána fogom közölni.

Átfutási idő és kommunikáció

Az első TestFlight vagy belső tesztelési verzió általában két héten belül elkészül, így az alkalmazást a kezében tartva adhat visszajelzést magáról a dologról, nem pedig képernyőképekről. A kiadási ellenőrzőlistát expliciten tartom – engedélyek, mélylinkek, offline viselkedés, áruházi metaadatok –, mert ezek azok az elemek, amelyek egy működő alkalmazást elutasított beküldéssé változtatnak. Minden kapott build egy olyan build, amelyet kiadhat.