Cum construiești aplicații mobile cross-platform fără regrete

Nu există un răspuns implicit

„Cross-platform sau nativ” se discută de obicei ca o chestiune de gust. Nu este. Este o întrebare despre lista de funcționalități, iar un răspuns greșit costă luni.

Am livrat în ambele feluri. Android în Kotlin cu detecție de documente cu OpenCV și un modul Kotlin Multiplatform partajat la Crossinx. Trei aplicații GlavUpDK, unde suita Avto e React Native cu Expo peste un backend FastAPI, iar clientul OTRS e nativ în mod deliberat. Și o aplicație iOS a mea, care vorbește cu un inel inteligent prin Bluetooth Low Energy.

Alege cross-platform când aplicația e în mare parte formulare și liste

Dacă ecranele sunt liste, formulare, o vedere de detaliu și un apel la API, un singur cod React Native e alegerea onestă. Plătești o dată pentru navigație, fluxul de autentificare și pipeline-ul de build, și primești ambele magazine.

Suita Avto se potrivește descrierii: comenzi de service, evidența vehiculelor, un login, un backend care există deja. Expo s-a ocupat de build, de actualizări și de publicarea în magazine, și nimic din toate astea nu a avut nevoie de platformă.

Alege nativ când funcționalitatea este platforma

Semnalul care decide e dacă funcționalitatea ta de bază e o capabilitate a platformei sau un ecran. Bluetooth, pipeline-uri de cameră, execuție în fundal, fuziune de senzori, stocare locală criptată. Dacă unul dintre ele este produsul, stratul cross-platform devine un strat de traducere între tine și hardware, iar proiectul îl petreci luptându-te cu el.

Aplicația pentru inel e cazul evident: citește un protocol binar specific dispozitivului prin BLE, gestionează reconectările, doarme între interogări. Nimic din toate astea nu are ce căuta în spatele unui bridge JavaScript.

Contează și offline-ul. Aplicația Gosti rulează la evenimente de protocol diplomatic, unde rețeaua poate să nu existe. Stocare locală criptată, o verificare biometrică înainte de export și blocarea capturilor de ecran sunt funcționalități pe care nu le-aș lua dintr-un plugin cross-platform și nu le-aș considera sigure.

Cum arată de fapt partajarea

Kotlin Multiplatform a fost cel mai bun compromis pe care l-am folosit: modelul domeniului, validarea și regulile de business stau o singură dată, compilate nativ pentru Android și iOS, în timp ce fiecare platformă își păstrează interfața. Împarți logica, nu ecranele. Astfel, părțile care merită împărțite rămân împărțite, fără să târăști interfața într-un compromis.

Bugetează pipeline-ul de lansare, nu doar codul

Build-ul și magazinul sunt locurile unde proiectele mobile alunecă de fapt. Chei de semnare, coduri de versiune, ferme de dispozitive de test, capturi de ecran, respingeri la review pentru declarații de confidențialitate lipsă. Automatizez tot: linii Fastlane pe iOS, EAS pe Android, CI care rulează testele pe dispozitive cu un prag de acoperire, așa că un build roșu nu poate deveni o lansare.

Munca asta e invizibilă într-un demo și face diferența dintre a livra lunar și a livra o singură dată.

Regula de decizie pe care o folosesc

Scrie lista de funcționalități, marchează fiecare element care are nevoie de platformă și numără. Zero sau unul, și cross-platform câștigă la cost. Trei sau mai multe, și nativul câștigă la timp, chiar dacă în prima zi pare mai scump.

Greșeala e să alegi codul după gust și apoi să descoperi întrebarea despre platformă în luna a patra, când arhitectura e deja modelată în jurul răspunsului greșit.