React Native: de la inițializarea proiectului la App Store și Google Play

Construiesc aplicații React și React Native de peste șapte ani și am trecut mai multe dintre ele prin review-ul App Store și Google Play. Printre ele sunt o aplicație de mobile banking pentru Moldova, cu integrări MAIB și MPass și abonamente prin RevenueCat, și o aplicație de dating, ambele construite ca angajat sau contractor pentru companiile care le dețin. La Syncra construim acum propria noastră aplicație mobilă, iBeep. E încă în dezvoltare și nu a ajuns în magazine.

Rareori codul e cel care amână o lansare. O amână tot ce e în jurul codului: semnarea, canalele de testare, declarațiile de confidențialitate, review-ul și primul update după lansare. Iată drumul pe care îl urmez, în ordine.

1. Pornește cu Expo și treci devreme la development builds

Pentru o aplicație React Native nouă, Expo e alegerea mea implicită. Chiar documentația React Native recomandă să pornești cu un framework, iar Expo e cel pe care îl folosesc majoritatea echipelor. Îți dă o structură de proiect rezonabilă, rutare bazată pe fișiere, un set mare de module native întreținute și un serviciu de build.

Două decizii contează de la început:

• ∿Folosește development builds, nu Expo Go, imediat ce adaugi un modul nativ pe care Expo Go nu îl include. Un development build e propria ta aplicație, cu un meniu de dezvoltare, și se comportă ca în producție acolo unde contează.
• ∿Lasă Expo să genereze proiectele native. Cu prebuild, folderele ios și android sunt generate din configurația aplicației, iar modificările native trec prin config plugins. Un upgrade devine o schimbare de configurație, nu un conflict de merge într-un proiect Xcode.

Rareori e nevoie de un proiect complet bare. Codul nativ custom își găsește loc și așa, ca modul Expo sau ca config plugin local.

2. Structurează repo-ul pentru mai multe aplicații

O aplicație mobilă e rareori singură. Mai există un API, un instrument de administrare, adesea și un landing page. Când toate stau într-un singur monorepo, pot folosi în comun tipuri, scheme de validare și constante, iar o schimbare în contractul API-ului apare ca eroare de tip în aplicație, nu ca un crash în producție.

iBeep e construit așa: un monorepo Turborepo cu aplicația Expo, API-ul și landing page-ul unul lângă altul. Păstrează granițele clare. Pachetele comune conțin tipuri și logică pură, niciodată cod React Native pe care serverul ar trebui să-l instaleze.

3. Separă mediile din prima zi

Configurează trei variante înainte să ai nevoie de ele: development, preview și production. Dă-i fiecăreia propriul bundle identifier și propriul nume de aplicație, ca toate trei să poată sta pe același telefon fără să se suprascrie. Ajunge un app.config.ts dinamic care citește o variabilă APP_VARIANT.

O regulă de repetat întregii echipe: tot ce e în bundle-ul aplicației e public. Variabilele cu prefixul EXPO_PUBLIC_ sunt compilate în JavaScript-ul care ajunge pe fiecare telefon. Secretele API stau pe server, iar aplicația vorbește cu serverul.

4. Configurează semnarea corect, o singură dată

Semnarea e etapa în care primele lansări pierd zile.

• ∿iOS cere înscrierea în Apple Developer Program, un certificat de distribuție și provisioning profiles. EAS le poate crea și gestiona pentru tine, și asta recomand, dacă nu ai un motiv anume să n-o faci.
• ∿Android are două chei. Cu Play App Signing, Google păstrează cheia care semnează ce instalează utilizatorii, iar tu păstrezi o cheie de upload. Fă backup la cheia de upload. Dacă o pierzi, poți cere resetarea, dar pierzi timp.
• ∿Alege cu grijă bundle identifier-ul și numele pachetului. Sunt permanente. Poți redenumi o aplicație, dar nu-i poți schimba identificatorul.

Versionarea are două numere pe fiecare platformă: versiunea pe care o văd oamenii și un număr de build care trebuie să crească la fiecare upload. Lasă serviciul de build să incrementeze numărul de build în locul tău, ca doi oameni să nu urce niciodată același număr.

5. Pune aplicația devreme pe telefoane reale

Simulatoarele ascund problemele care contează: dispozitive lente, rețele reale, notificări, deep links, cereri de permisiuni. Pune build-uri pe telefoane reale în primele săptămâni, nu în ultimele.

• ∿TestFlight duce un build la testerii interni la câteva minute după procesare.
• ∿Canalul de testare internă din Google Play face același lucru pe Android.

Ține cont în special de o regulă din Google Play. Un cont nou de dezvoltator personal trebuie să ruleze un test închis cu cel puțin 12 testeri, înscriși fără întrerupere timp de cel puțin 14 zile, înainte să poată cere acces la producție. Sunt două săptămâni pe care nu le poți comprima la final, așa că începe devreme sau publică de pe un cont de organizație, unde regula nu se aplică.

6. Completează formularele care blochează lansările

Ambele magazine te întreabă ce colectează aplicația și de ce, și ambele verifică.

• ∿Declarațiile de confidențialitate. Secțiunea App Privacy de la Apple și formularul Data safety (siguranța datelor) din Google Play trebuie să corespundă cu ce colectează efectiv aplicația și fiecare SDK din ea: analytics, raportarea crash-urilor, reclame, autentificare. Fă lista SDK-urilor înainte să completezi oricare dintre formulare.
• ∿Ștergerea contului. Dacă oamenii își pot crea cont în aplicație, Apple cere ca ștergerea lui să poată fi inițiată din aplicație. Google Play cere o cale în aplicație și un link web unde se poate cere ștergerea. Construiește asta ca funcție a aplicației, nu ca un e-mail către suport.
• ∿Privacy manifests pe iOS. Apple le cere pentru anumite API-uri de sistem, iar multe SDK-uri folosesc aceste API-uri. De obicei e suficient să ții SDK-urile la zi.
• ∿Autentificarea socială. Dacă oferi autentificare printr-un serviciu terț, Apple cere în general și o opțiune echivalentă, axată pe confidențialitate. În practică, asta înseamnă de obicei Sign in with Apple.
• ∿Plățile. Bunurile digitale și abonamentele folosite în aplicație trebuie, în general, să treacă prin sistemul de achiziții in-app al fiecărui magazin. Regulile diferă de la o regiune la alta și s-au tot schimbat, așa că verifică ghidurile actuale pentru piețele în care lansezi. Un serviciu de abonamente precum RevenueCat te scutește să scrii singur validarea chitanțelor pentru două magazine.

7. Pregătește-te pentru review

Majoritatea respingerilor pot fi evitate: un crash pe dispozitivul celui care face review-ul, un login fără cont demo, conținut placeholder, metadate care promit funcții pe care aplicația nu le are sau o declarație de confidențialitate care nu corespunde aplicației.

Scrie note de review care explică tot ce nu e evident, include un cont demo funcțional și lasă câteva zile de rezervă pentru prima trimitere. Review-urile următoare sunt de obicei mai rapide, dar la prima trimitere apar întrebările.

8. Planifică primul update înainte de lansare

Va trebui să livrezi un fix la câteva zile după lansare. Află dinainte cum.

• ∿Modificările de JavaScript și assets pot fi livrate ca update-uri over-the-air, de exemplu cu EAS Update, fără un nou review în magazin. Leagă fiecare update de o versiune de runtime, ca JavaScript-ul să nu ajungă niciodată într-un binar nativ pentru care n-a fost construit. Folosește-le pentru fix-uri și îmbunătățiri. Magazinele se așteaptă ca aplicația pe care o instalează oamenii să rămână aplicația care a trecut review-ul.
• ∿Modificările native, cum ar fi un modul nativ nou, o permisiune sau un upgrade de SDK, cer un build nou în magazin.
• ∿Lansează treptat. Phased release din App Store și staged rollouts din Google Play îți permit să livrezi întâi unei părți din utilizatori și să oprești dacă cresc rapoartele de crash.

Ține pasul cu cerințele platformelor. Google Play ridică în fiecare an cerința de target API level, iar Expo lansează SDK-uri noi de câteva ori pe an. Upgrade-urile mici și regulate costă mult mai puțin decât un upgrade mare la fiecare doi ani.

O listă scurtă înainte de trimitere

1. 1.Bundle identifier-ul și numele pachetului sunt finale, iar cele trei variante ale aplicației funcționează.
2. 2.Semnarea e gestionată, cheia de upload are backup.
3. 3.Testare pe dispozitive reale pe ambele platforme, inclusiv pe un telefon Android lent.
4. 4.Testul închis e pornit din timp, dacă contul tău Google Play îl cere.
5. 5.Declarațiile de confidențialitate corespund fiecărui SDK, ștergerea contului e implementată.
6. 6.Notele de review și contul demo sunt gata.
7. 7.Raportarea crash-urilor funcționează, iar calea de update e testată înainte de prima zi.

Cum lucrăm la Syncra

Ducem aplicații mobile de la un repo gol până în ambele magazine și le ținem în funcțiune după lansare: React Native și Expo, backend-ul din spatele lor și toată munca cu magazinele descrisă mai sus. iBeep, propria noastră aplicație, trece prin același drum. Când va ajunge în magazine, o vei găsi pe acest site.