React Native czy aplikacja natywna? Decyzja zaczyna się od wymagań

„Natywna czy cross-platformowa?” to częste pierwsze pytanie, ale samo w sobie nie opisuje produktu. Ważniejsze jest to, jakie funkcje ma zapewnić aplikacja, na jakich urządzeniach ma działać, jak będzie chroniła dane i kto będzie ją rozwijał po wydaniu. Ten tekst pomaga ułożyć te odpowiedzi w decyzję.

Co oznacza każde podejście

Aplikacja natywna powstaje w narzędziach i językach danej platformy: osobno dla iOS i osobno dla Androida. React Native pozwala budować interfejs mobilny w JavaScripcie lub TypeScripcie, a logikę aplikacji współdzielić między platformami. Szczegóły zależą od funkcji i użytych bibliotek.

„Wspólny kod” nie oznacza jednego identycznego interfejsu ani braku pracy platformowej. Integracje, wydajność, interakcje i wymagania systemowe trzeba sprawdzić dla konkretnego produktu.

Porównaj wymagania

Zanim wybierzesz technologię, odpowiedz na pytania:

• Czy aplikacja mocno zależy od funkcji systemu, urządzeń peryferyjnych lub pracy w tle?
• Czy zespołowi zależy na podobnym tempie rozwoju na iOS i Androidzie?
• Jak ważne są platformowe wzorce interakcji, dostępność i dopracowanie animacji?
• Czy istnieje już kod, kompetencje zespołu albo biblioteki, które trzeba utrzymać?
• Kto będzie aktualizował zależności i obsługiwał zmiany systemów operacyjnych?

Odpowiedzi wskażą obszary do prototypowania. Szczególnie ryzykowną integrację sprawdź przed zamrożeniem architektury.

Pięć kryteriów, według których porównujemy oba podejścia.

Bezpieczeństwo aplikacji mobilnej

Wybór technologii nie zwalnia z pracy nad bezpieczeństwem. Aplikacja mobilna działa na urządzeniu, którego nie kontrolujesz, więc wszystko, co w niej zapisano, może zostać odczytane. Dlatego korzystamy z OWASP MASVS, czyli międzynarodowego standardu wymagań dla aplikacji mobilnych, oraz z przewodnika testowego MASTG.

W praktyce sprawdzamy między innymi:

• gdzie leżą tokeny i dane użytkownika (bezpieczny magazyn systemu: Keychain na iOS, Keystore na Androidzie),
• czy w pliku instalacyjnym nie ma sekretów,
• czy komunikacja z serwerem jest zabezpieczona, w tym przypięcie certyfikatu tam, gdzie ma to sens,
• jak aplikacja obsługuje linki otwierające ją z zewnątrz (deep linki),
• czy logi nie zawierają danych osobowych.

Obie drogi wymagają tych samych kontroli. W React Native dochodzi jeszcze jedno: biblioteki zewnętrzne. Każda z nich to cudzy kod w Twojej aplikacji, więc skanujemy zależności przy każdej zmianie.

Uwzględnij koszt całego cyklu

Porównanie nie kończy się na pierwszej wersji. Uwzględnij konfigurację projektu, testowanie na urządzeniach, publikacje w sklepach, aktualizacje zależności, utrzymanie integracji oraz kompetencje potrzebne do diagnozowania problemów. Dwa podejścia mogą mieć podobny koszt początkowy, ale inne wymagania utrzymaniowe.

Po wydaniu praca trwa: systemy się zmieniają, a podatności wychodzą na jaw.

Trzy elementy tego cyklu zaskakują najczęściej:

• Sklepy. App Store i Google Play mają własne wymagania i procesy recenzji. Zmiany zasad mogą wymusić poprawki w aplikacji, która do tej pory działała.
• Nowe wersje systemów. Co roku iOS i Android zmieniają zasady, więc aplikacja wymaga aktualizacji, nawet jeśli nie dodajesz funkcji.
• Łatanie. Gdy w używanej bibliotece wyjdzie podatność, ktoś musi ją załatać i wydać nową wersję. Umowa na utrzymanie wskazuje, kto to robi i w jakim czasie. Więcej o kosztach piszemy w tekście Aplikacja działa, więc po co ją utrzymywać.

Nie przyjmuj też, że podejście cross-platformowe oznacza połowę pracy, ani że natywne zawsze daje zauważalnie lepsze doświadczenie. Wynik zależy od produktu, zespołu i jakości wykonania.

Jak czytać wyniki porównania

Porównanie rzadko daje jednoznaczny werdykt. Pomaga je czytać według prostych wskazówek, które trzeba sprawdzić na własnym produkcie.

• Gdy kluczowe funkcje opierają się głównie na ekranach, listach, formularzach i komunikacji z serwerem, wspólny kod często ułatwia utrzymanie jednej wersji produktu na obu platformach.
• Gdy produkt polega na głębokiej integracji z systemem, pracy w tle albo urządzeniach peryferyjnych, aplikacja natywna lub moduły natywne mogą dać większą kontrolę. Zawsze potwierdź to prototypem.
• Gdy zespół zna już jedną technologię, koszt jej zmiany liczy się tak samo jak koszt budowy.
• Gdy aplikacja przetwarza dane wrażliwe, wymagania bezpieczeństwa wpisz do zakresu przed wyborem technologii. Dodawanie ich po wyborze kosztuje więcej.

Zapisz uzasadnienie wyboru w jednym akapicie. Gdy za rok ktoś zapyta, dlaczego wybrano dane podejście, będziesz mieć gotową odpowiedź.

Pytania do wykonawcy

Zanim podpiszesz umowę, zapytaj o rzeczy, które wychodzą po wydaniu:

1. Kto publikuje aplikację w sklepach i na czyim koncie?
2. Jak często aktualizowane są zależności i kto za to odpowiada?
3. Jak wygląda kontrola bezpieczeństwa przed publikacją i czy dostanę jej raport?
4. Co się dzieje, gdy sklep odrzuci wersję albo wyjdzie krytyczna podatność?
5. Czy po zakończeniu współpracy dostanę kod, projekty i dostępy?

Wykonawca, który odpowiada na te pytania konkretnie, zwykle ma też uporządkowany proces. Tego, co usłyszysz, nie traktuj jak obietnicy. Poproś o zapis w umowie.

Zrób mały test decyzji

Przed dużą inwestycją przygotuj próbę najważniejszego ryzyka: na przykład wymaganej integracji, przepływu o wysokiej wydajności albo zachowania dostępności. Sprawdź ją na docelowych urządzeniach, z osobą, która będzie utrzymywać kod. Zapisz wynik, ograniczenia i koszt dalszego rozwiązania.

U nas taki test jest częścią etapu projektowania. Klikalny prototyp w Figmie pokazuje wygląd, a krótki prototyp techniczny sprawdza ryzykowną funkcję. Zmiana decyzji na tym etapie kosztuje godziny. Po napisaniu kodu kosztowałaby tygodnie.

Jak to wygląda w projekcie

Po wyborze technologii pracujemy w dwutygodniowych sprintach. Po każdym dostajesz działającą wersję do przetestowania, a środowisko testowe jest zawsze dostępne. Przed publikacją w sklepach wykonujemy audyt bezpieczeństwa i dostajesz jego raport razem z aplikacją. Szczegóły opisujemy w artykule Audyt bezpieczeństwa aplikacji.

Kod, projekty oraz konta w sklepach należą do Ciebie od pierwszego dnia. Dzięki temu zmiana wykonawcy w przyszłości nie wymaga negocjacji. Jeśli wybierasz wykonawcę, zobacz 9 pytań, po których widać, czy dowiozą.

Co zrobić dziś

Wypisz trzy funkcje, bez których aplikacja nie ma sensu, i przy każdej zaznacz, czy korzysta z funkcji urządzenia (kamera, Bluetooth, praca w tle, powiadomienia). Ta lista wskaże funkcję do pierwszego testu i będzie dobrym materiałem na rozmowę o technologii.

Porozmawiajmy o Twojej aplikacji

Jeśli nie wiesz, którą drogę wybrać, pierwsza rozmowa trwa około godziny i jest bezpłatna. Powiemy, co w Twoim przypadku przemawia za którym podejściem, i co sprawdzić prototypem. Opowiedz o swojej aplikacji.

Wniosek: Wybierz technologię po sprawdzeniu wymagań produktu i pracy zespołu. Nazwa frameworka nie zastąpi prototypu ryzykownych funkcji, kontroli bezpieczeństwa ani planu utrzymania.

Dalsza lektura: Zobacz projekt aplikacji mobilnej na telefon i tablet: Kokon.