PWA, Swift i Kotlin, albo Expo: wybór architektury aplikacji mobilnej

Architekturę wybraną dla aplikacji mobilnej trudno później zmienić. Jeśli dokonasz złego wyboru, następny rok spędzisz na walce z platformą zamiast na wdrażaniu nowych funkcji: konflikty zależności po aktualizacji frameworka, brakująca API sprzętowa lub oddzielanie się dwóch zespołów zajmujących się rozwojem aplikacji. Ten przewodnik porównuje trzy najczęściej stosowane rozwiązania – aplikacje Progressive Web Apps, w pełni natywne aplikacje napisane w Swift i Kotlin oraz Expo oparte na React Native – i kończy się konkretnymi kryteriami do wyboru między nimi, niezależnie od tego, czy budujesz MVP, czy planujesz kolejny etap rozwoju istniejącej aplikacji.

Jak porównują się te trzy opcje

Zanim przyjrzymy się każdej z opcji szczegółowo, oto w czym różnią się one pod względem kryteriów, które zwykle decydują o wyniku.

Baza kodu

• PWA: jedna baza kodu internetowego stworzona za pomocą HTML, CSS i JavaScript.

Natywny: oddzielna baza kodu dla każdej platformy – zazwyczaj Swift dla iOS i Kotlin dla Android.

Expo: jedna baza kodu w JavaScript lub TypeScript, współdzielona przez iOS i Android.

Dostępna w sklepach z aplikacjami

• PWA: dostępna w internecie. Informacja o aplikacji w sklepie jest opcjonalna i opiera się na narzędziach otaczających lub rozwiązaniach specyficznych dla danej platformy.
• Natywny i Expo: dystrybuowane bezpośrednio przez Apple App Store i Google Play.

Wydajność

• Natywny: maksymalna wydajność. Gładkie animacje przy pełnej częstotliwości odświeżania ekranu, nawet do 120 fps na nowoczesnych ekranach, bez żadnej warstwy abstrakcji.
• Expo: dla większości interfejsów bliskie rozwiązaniu natywnemu. React Native renderuje prawdziwe widoki natywne, a jego nowa architektura zastępuje stary asynchroniczny mostek bezpośrednimi wywołaniami z JavaScriptu do kodu natywnego za pośrednictwem JSI, co eliminuje długo istniejący wąskie gardło.
• PWA: ograniczone tym, co pozwala silnik przeglądarki, szczególnie jeśli chodzi o złożone animacje i prace w tle.

Dostęp do sprzętu

• Natywne: wszystko, co udostępnia platforma.
• Expo: szerokie pokrycie dzięki SDK Expo, rozszerzane o pluginy konfiguracyjne oraz dostosowane moduły natywne w razie potrzeby.
• PWA: podstawowy zestaw funkcji dostępnych w przeglądarce, takich jak kamera i lokalizacja geograficzna, z istotnymi brakami w systemie iOS.

Szybkość wydawania

• PWA: zmiany wchodzą w życie natychmiast po ich wdrożeniu, bez konieczności przeglądania przez sklep.
• Expo: aktualizacje przez sieć (OTA) mogą natychmiast dostarczyć zmiany w JavaScript i plikach, podczas gdy zmiany w kodzie natywnym nadal przechodzą przez standardową procedurę sprawdzania w sklepie.
• Native: każda wersja przechodzi przez proces sprawdzania w sklepie.

Koszt

• PWA: zazwyczaj najtańszy do stworzenia i utrzymania.
• Expo: umiarkowana inwestycja przy jednej zespole.
• Native: najdroższy, ponieważ dwa odrębne kodowanie platformy zwykle oznaczają dwie specjalistyczne zespoły.

Aplikacje webowe progresywne: podejście oparte na sieci

PWA to aplikacja internetowa, która wykorzystuje takie funkcje jak service worker oraz manifest aplikacji webowej, aby zachowywać się bardziej jak zainstalowana aplikacja: można ją dodać do ekranu głównego, uruchomić w osobnym oknie i nadal działać offline. Jeśli funkcjonowanie offline jest kluczowe dla twojego produktu, przewodnik z bloga na temat wsparcia offline za pomocą service worker wyjaśnia zasady jego działania.

Zalety. Nie ma sklepu aplikacji, który stanąłby pomiędzy tobą a twoimi użytkownikami. Każdy, kto zna adres URL, może korzystać z aplikacji i dodać ją do swojego ekranu głównego. Aktualizacje trafiają do wszystkich przy następnym załadowaniu, a treść może być indeksowana przez wyszukiwarki, co zapewnia organiczny ruch, którego rzadko osiąga się dzięki listom w sklepach.

Ograniczenia. Apple nadal ogranicza PWA na iOS. Funkcja Web Push jest dostępna tylko dla aplikacji umieszczonych na ekranie głównym, a wykonywanie w tle jest ściśle ograniczone. Safari w ogóle nie obsługuje Web Bluetooth oraz podobnych interfejsów sprzętowych. Jeśli produkt wymaga Bluetooth, ciągłego śledzenia w tle lub głębokiej integracji z urządzeniem, PWA szybko napotka problemy. Zasady platformy zmieniały się już kilkakrotnie, dlatego sprawdź aktualny stan dla wybranych wersji iOS.

Natywny Swift i Kotlin: maksymalna kontrola

Rozwój w formacie natywnym oznacza konieczność tworzenia i utrzymywania dwóch aplikacji: jednej w języku Swift dla iOS oraz drugiej w Kotlinie dla Androida.

Mocne strony. Nic nie jest abstrahowane, więc wydajność i jakość są tak dobre, jak tylko pozwala na to platforma. Nowe API od Apple i Google są dostępne w dniu ich wydania, bez konieczności czekania na framework, który je otoczy. Jest to naturalny wybór dla wymagających zastosowań graficznych, złożonej rzeczywistości rozszerzonej lub wirtualnej oraz intensywnego przetwarzania w tle.

Ograniczenia. Nakład pracy jest znaczny. Dwa odrębne kodbazy mniej więcej podwajają wysiłki związane z rozwojem i testowaniem oraz zazwyczaj wymagają dwóch zespołów o różnych umiejętnościach. Każdą funkcjonalność trzeba budować dwa razy i utrzymywać je w synchronizacji, a każde wydanie, nawet to z małym poprawką błędu, musi czekać na przegląd w sklepie.

Expo: jeden kodbase, efekty natywne

Expo to framework i zestaw narzędzi o otwartym kodzie źródłowym, stworzony na bazie React Native. Ukrywa on dużą część złożoności budowania aplikacji natywnych na iOS i Android, dzięki czemu jeden kod napisany w JavaScript lub TypeScript może tworzyć prawdziwe aplikacje natywne dla obu platform.

Mocne strony. Rozwój przebiega szybko. Expo Application Services (EAS) buduje pliki binarne natywne w chmurze, więc codzienna praca rzadko wymaga otwierania Xcode lub Android Studio. EAS Update dostarcza poprawki typu OTA bezpośrednio do zainstalowanych aplikacji. Należy pamiętać, że aktualizacje OTA mogą zmieniać kod JavaScript i pliki assets, ale nie kod natywny, a zasady sklepu nadal określają, co może zostać zmienione; nowa zależność natywna oznacza konieczność ponownego skompilowania aplikacji w sklepie.

Ograniczenia. Wtyczki konfiguracyjne oraz API Expo Modules API sprawiły, że tworzenie własnego kodu natywnego stało się znacznie łatwiejsze niż kiedyś, a wersje rozwojowe pozwalają na dodanie dowolnej biblioteki natywnej, a nie tylko tych dostępnych w Expo Go. Mimo to aplikacje wymagające sterowników sprzętowych na bardzo niskim poziomie lub złożonego kodu C++ nadal wymagają prawdziwej pracy nad kodem natywnym, a zespół potrzebuje kogoś, kto potrafi to robić.

Aby zapoznać się z szerszym wyborem rozwiązań międzyplatformowych poza Expo, w tym z Flutter i Kotlin Multiplatform, sprawdź przegląd ramworków mobilnych międzyplatformowych na blogu.

Wybór odpowiedniej architektury

Należy dopasować architekturę do produktu, a nie do ulubionego narzędzia zespołu:

1. Wybierz PWA, gdy budżet jest ograniczony, ważna jest widoczność w wynikach wyszukiwania, a produkt składa się głównie z treści lub formularzy: sklepu internetowego, strony informacyjnej czy panelu sterowania typu SaaS. To również rozsądny sposób na weryfikację popytu przed zainwestowaniem w aplikacje do sklepu.
2. Wybierz Expo dla startupu, wersji MVP lub aplikacji produkcyjnej, która musi szybko dotrzeć zarówno do App Store, jak i Google Play przy udziale jednej zespołu. Obejmuje to większość aplikacji biznesowych i konsumenckich.
3. Wybierz wersję natywną dla gier wysokiej jakości, produktów wymagających mocnego sprzętu, takich jak urządzenia do ćwiczeń synchronizujące się ciągle przez Bluetooth, lub wszelkich aplikacji, gdzie interfejsy 120 fps i brak ryzyka abstrakcji stanowią rzeczywiste wymagania.

Te opcje nie stanowią trwałych, izolowanych rozwiązań. Aplikacja PWA może współistnieć z aplikacją ze sklepu, a aplikacja Expo może zawierać moduły natively napisane w Swift i Kotlin, więc często istnieje hybrydowe rozwiązanie, gdy jedna z części produktu przewyższa możliwości standardowych rozwiązań.

Podsumowanie

Żadne z tych trzech rozwiązań nie jest ogólnie lepsze. Prawidłowa odpowiedź zależy od tego, co produkt musi robić na urządzeniu, jak szybko musisz dotrzeć do użytkowników oraz ile inżynierów możesz sobie pozwolić. Odpowiedz na te trzy pytania przed napisaniem kodu: koszt błędnego wyboru objawia się później w postaci konieczności przerabiania kodu i szukania workaroundów na poszczególnych platformach, natomiast właściwy wybór pozwala zespołowi skupić się na funkcjach, które faktycznie przyciągają uwagę użytkowników.

Literatura pokrewna

• Dlaczego opuszczenie React Native przez Shopify nie zagraża Expo — Wyjaśnia, dlaczego przejście Shopify z React Native na natywny Swift i Kotlin nie oznacza końca rozwoju aplikacji wieloplatformowych w Expo dla większości zespołów.
• Planowanie aktualizacji do Expo SDK 58: iOS 27, React Native 0.88 i nowe narzędzia — Praktyczny przegląd wersji beta Expo SDK 58: jakie zmiany dotyczą iOS 27 i React Native 0.88, które funkcje są eksperymentalne oraz jak bezpiecznie przetestować aktualizację.