W przypadku większości aplikacji biznesowych wybór między React Native a Flutter ma znacznie mniejsze znaczenie, niż sugerują to spory między tymi dwoma dostawcami. Jeśli Twoja aplikacja składa się głównie z formularzy, list, map i powiadomień push, oba frameworki bez problemu umożliwią jej udostępnienie w obu sklepach. Zazwyczaj wybieramy React Native, a główny powód nie ma charakteru technicznego. Programistów znających JavaScript i TypeScript znacznie łatwiej jest znaleźć, dzięki czemu po przekazaniu aplikacji będziesz mógł samodzielnie ją utrzymywać. Wybór frameworka staje się naprawdę istotny dopiero wtedy, gdy Twoja aplikacja wymaga zaawansowanej grafiki, intensywnych operacji w tle, obsługi Bluetooth lub nietypowych modułów natywnych.
Prawdziwe pytanie dotyczące porównania React Native i Flutter
Kiedy dwaj dostawcy przedstawiają ci sprzeczne zalecenia, zazwyczaj odpowiadają na różne pytania. Jeden z nich pyta, który framework zapewnia najpłynniejszą animację w teście porównawczym. Drugi pyta, który framework jest najlepiej znany jego własnemu zespołowi. Żaden z nich nie zadaje pytania, które ma znaczenie dla Ciebie jako osoby płacącej za aplikację: kto będzie w stanie zmodyfikować ten kod za dwa lata i ile to będzie kosztować?
Oba frameworki rozwiązują ten sam podstawowy problem. Tworzenie aplikacji wieloplatformowych pozwala jednemu zespołowi napisać jeden kod źródłowy, który działa na systemach iOS i Android, zamiast tworzyć równolegle dwie aplikacje natywne. Branżowy wskaźnik oszczędności w tym zakresie wynosi około 30–40% w porównaniu z dwoma oddzielnymi kompilacjami natywnymi. W naszym artykule na temat ile kosztuje stworzenie aplikacji i czy rozwiązanie wieloplatformowe rzeczywiście pozwala zaoszczędzić pieniądze. Taką oszczędność uzyskasz niezależnie od tego, który framework wybierzesz. Nie jest to powód, by preferować jeden z nich nad drugim.
Zatem sensowne porównanie nie polega na tym, “która opcja jest szybsza”, ale na tym, w jakich obszarach te dwie opcje faktycznie różnią się pod względem działania, oraz czy Twoja aplikacja korzysta z któregokolwiek z tych obszarów.
Jak ten wybór faktycznie przekłada się na realizację zamówienia
W czym React Native i Flutter naprawdę się różnią
Różnica techniczna jest rzeczywista i łatwo ją wyjaśnić. Tworzenie aplikacji w React Native opiera się na języku JavaScript lub TypeScript i wykorzystuje natywne komponenty interfejsu użytkownika danej platformy. Przycisk w systemie iOS to przycisk iOS. Tworzenie aplikacji w Flutterze opiera się na języku Dart i polega na samodzielnym rysowaniu każdego piksela za pomocą własnego silnika renderującego. Przycisk w Flutterze wygląda tak samo na obu platformach, ponieważ to Flutter go narysował.
Właśnie ta jedna różnica wyjaśnia większość kompromisów, o których będziecie słyszeć:
| Czynnik | React Native | Trzepotanie |
|---|---|---|
| Język | JavaScript / TypeScript | Dart |
| Renderowanie interfejsu użytkownika | Natywne komponenty platformy | Własny silnik renderujący, taka sama liczba pikseli na obu platformach |
| Niestandardowy interfejs użytkownika identyczny co do piksela | To możliwe, ale wymaga więcej wysiłku | Poważne opóźnienie w spłacie |
| Wygląd i styl platformy | Domyślne zachowanie | Trzeba to odtworzyć |
| Pula kandydatów | Bardzo szerokie (programiści stron internetowych i aplikacji mobilnych) | W węższym znaczeniu Dart jest używany głównie w Flutterze |
| Współpraca z zespołem internetowym w zakresie kodu lub personelu | To naturalne, jeśli strona internetowa działa w oparciu o React | Ograniczona |
| Dostęp do funkcji urządzenia | Za pomocą modułów natywnych | Za pośrednictwem kanałów platformy / wtyczek |
Zwróć uwagę na to, czego brakuje w tabeli: “może stworzyć aplikację do rezerwacji”, “może wyświetlać mapę”, “może wysyłać powiadomienia push”. Obie platformy to potrafią. W przypadku typowej aplikacji zlecanej przez założyciela obie platformy są dojrzałe, obie posiadają biblioteki do uwierzytelniania, płatności, map i analityki, a także obie umożliwiają publikację w App Store i Google Play w standardowy sposób.
Gdy to właśnie ramy decydują o wyniku
Wybór zaczyna mieć znaczenie, gdy Twoja aplikacja w znacznym stopniu opiera się na czymś, czego framework nie obsługuje natywnie:
- Wymagająca grafika i niestandardowe animacje. Jeśli produkt jest w zasadzie niestandardowym obszarem roboczym (narzędziem do rysowania, interfejsem przypominającym grę lub interfejsem użytkownika z wyraźnymi elementami brandingowymi i złożonymi animacjami), zaletą jest własny silnik renderujący Fluttera.
- Prace przygotowawcze. Zadania długotrwałe, ciągłe śledzenie lokalizacji, operacje przesyłania danych, które muszą zostać zakończone po zamknięciu aplikacji. W tym przypadku zmagasz się z ograniczeniami systemu operacyjnego, a nie z samym frameworkiem, i tak czy inaczej będziesz musiał pisać kod dostosowany do konkretnej platformy.
- Bluetooth i sprzęt. Urządzenia medyczne, urządzenia do noszenia na ciele, czujniki IoT. O powodzeniu projektu decyduje jakość dostępnych modułów natywnych oraz zdolność Twojego zespołu do tworzenia własnych rozwiązań.
- Konkretne natywne zestawy SDK. Terminal płatniczy, zastrzeżony zestaw SDK dostawcy, biblioteka AR. Przed wyborem frameworku sprawdź, czy istnieje dla niego aktualizowana nakładka – nie po dokonaniu wyboru, tylko przed.
Jeśli żadna z tych cech nie odnosi się do Twojej aplikacji, to nie framework zadecyduje o sukcesie projektu. Decydujące znaczenie będą miały zakres projektu, zespół oraz jakość zaplecza.
Kiedy wieloplatformowość przestaje być właściwym rozwiązaniem
Czasami szczera odpowiedź na pytanie “Flutter czy React Native” brzmi: “żadne z nich”. Jeśli główna wartość Twojego produktu tkwi w samym urządzeniu (stały dostęp do czujników, głęboka integracja z funkcjami platformy, które pojawiają się najpierw w natywnych zestawach SDK, przetwarzanie multimediów o krytycznym znaczeniu dla wydajności), to i tak większość Twojego kodu będzie specyficzna dla danej platformy. W takiej sytuacji wspólna baza kodu jest jedynie cienką warstwą nakładającą się na dwie aplikacje natywne, a Ty płacisz za tę abstrakcję, nie czerpiąc z niej zbyt wielu korzyści. Tańszym rozwiązaniem mogą być dwie aplikacje natywne lub najpierw aplikacja natywna na jednej platformie.
Grupa kandydatów do pracy i koszty tej decyzji dwa lata później
To właśnie ten czynnik bierzemy pod uwagę w największym stopniu, a dostawcy rzadko o nim wspominają. Aplikacja nie jest gotowa w momencie premiery. Systemy operacyjne są aktualizowane co roku, zmieniają się zasady sklepów, biblioteki stają się przestarzałe, a użytkownicy będą oczekiwać nowych funkcji. Nasza analiza koszty tworzenia aplikacji mobilnych w Europie, w tym budżet na bieżącą konserwację pokrywa zwykle związane z tym koszty utrzymania.
Ważniejsze jest to, kto wykonuje tę pracę, niż framework, w którym jest ona napisana. Rynek pracy dla programistów JavaScript i TypeScript jest bardzo szeroki, ponieważ te same umiejętności są wykorzystywane w całym sektorze tworzenia stron internetowych. Kod w React Native może zostać przejęty przez wiele agencji i freelancerów, a także przez programistę stron internetowych, który jest gotów nauczyć się programowania aplikacji mobilnych. Język Dart jest używany głównie w Flutterze, więc grono osób potrafiących zajmować się utrzymaniem aplikacji Flutter jest węższe. Nie jest ono małe, ale będziesz mieć mniej opcji, gdy będziesz potrzebować kogoś w krótkim czasie.
To kwestia łatwości utrzymania kodu, a nie kwestia wyboru frameworka. Wolimy pozostawić klientowi kod, nad którym może pracować wiele zespołów, niż kod, który tylko my lub kilku specjalistów potrafi wygodnie utrzymywać.
Przykład z naszej praktyki: „Skarby Górali” i „Questy”
Skarby Górali to aplikacja mobilna, którą stworzyliśmy dla Fundacji Mapa Pasji. Dzięki kalendarzowi wydarzeń i funkcji geolokalizacji przybliża użytkownikom kulturę góralską, umożliwiając im wyszukiwanie wydarzeń i miejsc w pobliżu. Aplikacja została stworzona w technologii React Native i jest dostępna zarówno w App Store, jak i w Google Play.
Dlaczego React Native? Nie dlatego, że Flutter nie dałby rady tego zrealizować. Kalendarz wydarzeń, ekrany z treścią i wyszukiwanie oparte na lokalizacji to właśnie te obszary – formularze, listy i mapy – w których oba frameworki sprawdzają się równie dobrze. Wybraliśmy React Native, ponieważ pozwala on na utrzymanie kodu w języku, który jest zrozumiały dla szerokiego grona programistów, co zapewnia klientowi prawdziwą swobodę w przyszłości. Jeśli kiedykolwiek zechce on przenieść prace programistyczne do własnej firmy lub zmienić dostawcę, nie będzie musiał szukać specjalistów o rzadkich umiejętnościach.
Ten sam klient zwrócił się do nas później z kolejnym produktem, Questy, który również został stworzony w oparciu o React Native. Użycie tego samego stosu technologicznego w obu aplikacjach oznacza wspólną wiedzę, znane narzędzia oraz jeden profil kandydata zamiast dwóch.
Questy pokazuje również, gdzie leżą prawdziwe kompromisy inżynieryjne. Lokalizacja ma kluczowe znaczenie dla produktu, a trudnym pytaniem nigdy nie było “React Native czy Flutter”. Chodziło o to, jak zrównoważyć dokładność GPS z zużyciem baterii: jak często wysyłać zapytania o pozycję, jak precyzyjna musi ona być w każdym momencie oraz kiedy pozwolić urządzeniu na odpoczynek. Decyzje te dotyczą poziomu usług lokalizacyjnych systemu operacyjnego oraz zachowania produktu. Każdy framework stanąłby przed tym samym dylematem, a odpowiedź byłaby taka sama.
Na co zwrócić uwagę
- Testy porównawcze jako argument sprzedażowy. Porównania szybkości renderowania rzadko oddają rzeczywiste wrażenia z użytkowania aplikacji zawierającej formularze, listy i mapę. Zapytaj dostawcę, który ekran w twój aplikacja różniłaby się w sposób zauważalny.
- Strefa komfortu sprzedawcy przedstawiona jako zalecenie. Zespół, który tworzy oprogramowanie wyłącznie w jednym frameworku, zawsze będzie go polecał. Nie ma w tym nic złego, o ile otwarcie o tym mówi. Zapytaj, co by wybrali, gdyby to nie oni zajmowali się utrzymaniem aplikacji.
- Niesprawdzone moduły natywne. Jeśli Twoja aplikacja wymaga obsługi Bluetooth, konkretnego zestawu SDK lub długotrwałych zadań w tle, przed podpisaniem umowy zapytaj o konkretną bibliotekę lub sposób realizacji. Odpowiedź “Jest na to wtyczka” nie jest wystarczająca, dopóki ktoś nie sprawdzi, czy jest ona aktualizowana.
- Nie biorąc pod uwagę tego, kto będzie się tym zajmował po premierze. Zadaj sobie pytanie: gdyby ten dostawca zniknął jutro, jak trudno byłoby zatrudnić kogoś, kto przejąłby jego obowiązki? Odpowiedź na to pytanie jest zazwyczaj ważniejsza niż jakakolwiek funkcja frameworka.
- Założenie, że aplikacja będzie działać na różnych platformach, oznacza o połowę mniej pracy. Jedna baza kodu nie oznacza, że testy zakończą się sukcesem. Nadal trzeba przeprowadzać testy na obu platformach, a funkcje specyficzne dla danej platformy nadal wymagają wysiłku dostosowanego do tej platformy.
- Bezpodstawne mieszanie zestawów produktów z różnych linii. Jeśli masz już jedną aplikację opartą na jednym frameworku, druga aplikacja oparta na innym frameworku podwaja liczbę umiejętności, które musisz posiadać.
Wniosek
Wybór między React Native a Flutter ma sens tylko wtedy, gdy Twoja aplikacja opiera się na rozbudowanej grafice, długotrwałych procesach działających w tle, Bluetooth lub konkretnych modułach natywnych. W przypadku większości aplikacji obie platformy sprawdzą się równie dobrze, a czynnikiem decydującym jest to, jak łatwo będzie znaleźć osoby, które będą w stanie utrzymać aplikację w dobrym stanie po jej uruchomieniu. Właśnie dlatego zazwyczaj wybieramy React Native: szeroka pula kandydatów i łatwa w utrzymaniu baza kodu lepiej chronią Twoją inwestycję niż zwycięstwo w testach porównawczych. Jeśli rozważasz sprzeczne rekomendacje, zapoznaj się z naszym podejściem do rozwój produktu. Najpierw ustalamy, jakie zadania ma spełniać aplikacja i kto będzie się nią zajmował, a dopiero potem wybieramy narzędzie.
