Când vrei o aplicație pentru iOS și Android, una dintre primele întrebări e „cum o construim?”. Răspunsul influențează costul, termenul, viteza aplicației și cât de ușor o vei actualiza peste doi ani.
Sunt, în mare, trei drumuri: aplicații native, o aplicație cross-platform sau o aplicație hibridă, care îmbină o aplicație web cu funcțiile native ale telefonului. Niciunul nu e cel mai bun în orice situație.
Aplicațiile native: câte una pentru fiecare platformă
Aplicația de iOS se scrie în Swift, cea de Android în Kotlin, fiecare cu uneltele oficiale ale platformei.
Ce câștigi:
- cea mai bună performanță și cele mai fluide animații;
- acces complet la telefon: cameră, senzori, Bluetooth, notificări, funcționare în fundal;
- funcțiile noi ale sistemelor de operare, disponibile din prima zi;
- aspectul și comportamentul cu care utilizatorii fiecărei platforme sunt obișnuiți.
Ce plătești: două aplicații separate, deci aproape dublul muncii la dezvoltare și la fiecare actualizare.
Merită pentru aplicații unde experiența pe telefon e chiar produsul: jocuri, aplicații foto și video, aplicații care merg mult offline sau care lucrează intens cu hardware-ul.
Cross-platform: o singură bază de cod
Cu Flutter sau React Native, scrii aplicația o singură dată și obții două aplicații, pentru iOS și pentru Android.
Ce câștigi:
- un singur cod, deci cost și timp de dezvoltare mai mici;
- performanță apropiată de cea nativă pentru majoritatea aplicațiilor;
- aceeași logică și același aspect pe ambele platforme.
Ce trebuie să știi:
- funcțiile speciale ale telefonului se folosesc prin module intermediare; când un modul lipsește, se scrie cod nativ;
- depinzi de cadrul ales și de actualizările lui;
- la funcții noi ale sistemelor de operare, aștepți uneori să fie suportate de cadru.
E alegerea potrivită pentru majoritatea aplicațiilor de business: conturi, liste, formulare, rezervări, comenzi, plăți.
Aplicația hibridă: web-ul plus funcțiile native
A treia variantă pornește de la o observație simplă: multe afaceri au deja o aplicație web bună, iar pe telefon au nevoie de ea, plus de câteva lucruri pe care doar o aplicație le poate face bine.
Așa am construit aplicațiile pentru inMotion, platforma de management pentru școli și studiouri private (de dans, fotbal, karate și multe altele). Membrii și personalul își văd abonamentele, clasele, plățile și documentele din telefon, iar la fiecare ședință se face check-in rapid, cu un cod QR.
Concret, aplicația inMotion are două părți:
- o aplicație nativă pentru iOS și una pentru Android, care conțin un WebView, adică o fereastră în care se încarcă interfața aplicației web, direct de pe server;
- o punte nativă între interfață și telefon: când utilizatorul apasă „Scanează”, interfața îi cere aplicației native să deschidă camera, iar scanarea codului QR se face nativ, cu semnal sonor și vizual de confirmare. Tot nativ vin notificările push și descărcarea documentelor PDF.
Ce câștigi:
- aplicația e mereu actualizată. Interfața se încarcă de pe server, deci o funcție nouă sau o corectură ajunge la toți utilizatorii imediat, fără să aștepți o nouă versiune în magazinele de aplicații;
- un singur cod pentru web, iOS și Android. Aceleași ecrane, aceleași date, aceleași reguli, oriunde ar lucra utilizatorul;
- funcțiile telefonului sunt native, deci rapide și fiabile acolo unde contează: camera, notificările, fișierele;
- cost mai mic decât trei aplicații separate.
Ce trebuie să știi:
- aplicația are nevoie de internet pentru interfață; nu e potrivită pentru aplicații care trebuie să meargă mult offline;
- pentru animații complexe sau ecrane foarte grele, o interfață nativă rămâne mai fluidă;
- o aplicație care doar afișează un site nu e acceptată. Regulile Apple cer explicit ca o aplicație să aducă mai mult decât „un site reambalat”1. De aceea, funcțiile native nu sunt un moft, ci motivul pentru care aplicația există: scannerul, notificările și documentele fac din ea o unealtă, nu un browser.
Și varianta fără magazin de aplicații
Pentru unele proiecte, nici nu e nevoie de o aplicație în App Store sau Google Play. O aplicație web instalabilă (PWA) poate fi adăugată pe ecranul telefonului și, de la iOS 16.4, poate primi și notificări pe iPhone2. Are însă acces mai limitat la funcțiile telefonului decât o aplicație nativă.
Pe scurt
| Ce comparăm | Nativă | Cross-platform | Hibridă (web + nativ) |
|---|---|---|---|
| Coduri de întreținut | două | unul | unul (web), plus o parte nativă mică |
| Cost de dezvoltare | cel mai mare | mediu | cel mai mic, dacă există deja aplicația web |
| Performanță | cea mai bună | foarte bună | bună; nativă unde contează |
| Acces la telefon | complet | aproape complet | ce expune puntea nativă |
| Actualizări | prin magazinele de aplicații | prin magazinele de aplicații | interfața, instant, de pe server |
| Offline | complet | complet | limitat |
Cum alegem
Înainte de tehnologie, stabilim împreună ce trebuie să facă aplicația și pentru cine:
- Ai deja o platformă web și ai nevoie de ea pe telefon, plus câteva funcții native? Aplicația hibridă e, de obicei, cea mai eficientă.
- Aplicația e nouă și are o logică de business obișnuită? Cross-platform, cu Flutter sau React Native.
- Experiența pe telefon e chiar produsul, lucrezi mult offline sau cu hardware-ul? Nativ.
Construim aplicații în toate cele trei variante și le publicăm în App Store și Google Play. Îți recomandăm varianta care îți aduce aplicația potrivită cu cel mai mic cost de întreținere, nu pe cea mai la modă.
Vezi cum facem aplicațiile mobile
Apple, App Store Review Guidelines, regula 4.2 (Minimum Functionality): aplicația trebuie să aibă funcții, conținut și interfață care o ridică deasupra unui „repackaged website”. ↩
WebKit, Web Push for Web Apps on iOS and iPadOS. ↩
Imaginea de copertă: Dennis Cortés, Wikimedia Commons (CC0)
.jpg){kind=link}