Jeśli zamawiasz aplikację mobilną, prędzej czy później usłyszysz to pytanie: React Native, Flutter czy natywnie? Brzmi jak spór programistów i trochę nim jest. Tylko że płacisz za niego Ty, i to przez całe życie aplikacji. Dlatego rozbiorę go na to, co obchodzi właściciela firmy: pieniądze, czas i spokój po starcie.
Od razu uczciwie: na co dzień pracuję w React Native. Biorę na to poprawkę i powiem też, kiedy wybrałbym coś innego.
Trzy drogi w jednym zdaniu każda
- Natywnie. Dwie osobne aplikacje: jedna na iPhone’a, druga na Androida. Dwa projekty, często dwa zespoły.
- React Native. Jedna aplikacja na oba systemy, w tym samym języku, w którym powstaje większość stron internetowych.
- Flutter. Też jedna aplikacja na oba systemy, ale we własnym języku i z własnym sposobem rysowania ekranów.
Dwie ostatnie drogi to tak zwane rozwiązania wieloplatformowe. Dla użytkownika różnicy zwykle nie widać: aplikacja wygląda i działa jak „prawdziwa”, bo nią jest.
Co decyduje o wyborze
Budżet: raz czy dwa razy
Natywnie każdą funkcję budujesz dwa razy i dwa razy ją utrzymujesz. Logowanie, koszyk, powiadomienia: wszystko w dwóch wersjach, które z czasem zaczynają się rozjeżdżać. W React Native i we Flutterze większość pracy robisz raz. W typowej aplikacji biznesowej to różnica rzędu połowy budżetu, na starcie i potem przy każdej kolejnej zmianie.
Czas do pierwszej wersji
Jeden projekt zamiast dwóch to szybsza pierwsza wersja w rękach użytkowników, a dopiero ona pokaże Ci, czy pomysł działa, zanim wydasz resztę pieniędzy.
Strona i aplikacja z jednej bazy
Tu React Native ma przewagę, o której rzadko się mówi. Jeśli masz albo planujesz aplikację w przeglądarce, spora część logiki może być wspólna dla strony i telefonu. W Omni Solutions z jednego projektu powstaje wersja na stronę, iPhone’a i Androida, a całość rozwijają dwie osoby.
Flutter też potrafi zbudować wersję w przeglądarce, ale do stron, które mają być znajdowane w Google, nadaje się słabo.
Poprawki bez czekania na sklep
Każda wersja aplikacji przechodzi recenzję w App Store i Google Play. W React Native drobne poprawki można wysłać użytkownikom od razu, z pominięciem tej kolejki. To standardowa, dobrze znana ścieżka. We Flutterze da się to zrobić dodatkowym narzędziem, natywnie praktycznie wcale. Kiedy w piątek wieczorem wyjdzie błąd w płatnościach, ta różnica przestaje być teoretyczna.
Kto przejmie projekt po mnie
Pytanie, które warto zadać każdemu wykonawcy. React Native korzysta z najpopularniejszego języka w sieci, więc ludzi, którzy go znają, jest najwięcej. Flutter ma mniejszą, ale żywą społeczność. Natywnie potrzebujesz dwóch różnych specjalistów, osobno na każdy system. Im łatwiej znaleźć następcę, tym mniej jesteś uzależniony od jednej firmy, również ode mnie.
Porównanie w skrócie
| Kryterium | Natywnie | React Native | Flutter |
|---|---|---|---|
| Ile projektów | dwa | jeden | jeden |
| Koszt budowy i utrzymania | najwyższy | niższy | niższy |
| Wspólny kod ze stroną www | nie | tak | ograniczony |
| Szybkie poprawki bez sklepu | nie | tak, standardowo | z dodatkowym narzędziem |
| Dostęp do specjalistów | dwie osobne grupy | największa pula | mniejsza pula |
| Grafika, gry, nietypowy sprzęt | najlepiej | wystarczająco | dobrze |
Kiedy natywnie
Natywnie wybrałbym bez wahania, gdy aplikacja to gra albo zaawansowana grafika, gdy mocno korzysta z nietypowego sprzętu (specjalistyczne czujniki, rozszerzona rzeczywistość) albo gdy ma działać tylko na jednym systemie, na przykład na firmowych iPadach. Wtedy jedna baza dla dwóch systemów niczego nie oszczędza, a własne ograniczenia wnosi.
Kiedy Flutter
Flutter ma sens, gdy Twój zespół już go zna i dobrze się w nim czuje albo gdy aplikacja ma mieć bardzo własny, „markowy” wygląd, identyczny co do piksela na obu systemach. Przemawia za nim też brak planów na stronę w przeglądarce, która miałaby dzielić z aplikacją kod.
Kiedy React Native
W większości aplikacji biznesowych: rezerwacje, zamówienia, aplikacje dla klientów i pracowników, narzędzia terenowe. Szczególnie wtedy, gdy masz albo planujesz też aplikację w przeglądarce i gdy zależy Ci na szybkich poprawkach. Przy platformie smart-home Sinum wspólny kod dla telefonu i przeglądarki był jednym z powodów, dla których nowe wersje powstawały o połowę krócej.
O co zapytać wykonawcę
- Dlaczego ta technologia, a nie inna, w moim przypadku? Dobra odpowiedź mówi o Twojej aplikacji, nie o tym, co wykonawca lubi.
- Ile będzie kosztować utrzymanie przez pierwszy rok? Budowa to dopiero początek rachunku.
- Jak szybko wypuścicie pilną poprawkę? Godziny czy dni?
- Kto przejmie projekt, jeśli się rozstaniemy? Kod i konta w sklepach powinny być Twoje od pierwszego dnia.
Zastanawiasz się, która droga pasuje do Twojego pomysłu? Zobacz, jak pracuję przy aplikacjach mobilnych, albo umów bezpłatną rozmowę. Jeśli w Twoim przypadku lepsza będzie aplikacja natywna, usłyszysz to ode mnie wprost.