Kiedy polecamy Fluttera, a kiedy go odradzamy
Flutter jest dziś naszym domyślnym wyborem dla aplikacji biznesowych na dwie platformy, ale nie jedynym. Poniżej sytuacje, w których go proponujemy, i te, w których uczciwie mówimy, że lepszy będzie Kotlin albo Swift.
Polecamy Fluttera, gdy:
- aplikacja jest dla klientów zewnętrznych i musi działać jednocześnie na Androidzie i iOS,
- funkcje to typowy zestaw biznesowy: konta, katalog, zamówienia, płatności, mapy, powiadomienia push, skanowanie kodów,
- budżet ma wystarczyć także na backend i panel administracyjny, a nie tylko na dwie aplikacje,
- chcesz, żeby nowa funkcja pojawiała się na obu platformach w tym samym dniu,
- budujesz MVP, które ma szybko trafić do pierwszych użytkowników.
Odradzamy Fluttera, gdy:
- aplikacja to gra albo grafika 3D w czasie rzeczywistym - tu lepszy jest silnik gier,
- większość funkcji to elementy systemowe: widżety na ekranie głównym, zegarki, CarPlay i Android Auto, rozbudowana praca w tle,
- Twoja firma ma już dwa zespoły natywne, które będą utrzymywać aplikację po wdrożeniu,
- potrzebujesz nowości z iOS lub Androida w dniu premiery systemu - wtyczki Fluttera dostają je z opóźnieniem.
Jeśli projekt jest na granicy, proponujemy Fluttera z modułami natywnymi dla jednej–dwóch funkcji sprzętowych. To częsty kompromis: wspólny kod dla większości ekranów i kod natywny tylko tam, gdzie jest naprawdę potrzebny.
Flutter, natywnie, React Native czy Kotlin Multiplatform - porównanie
Cztery drogi do aplikacji na Androida i iOS. Koszt porównujemy względnie, dla aplikacji o tym samym zakresie.
| Kryterium | Flutter | Natywnie (Kotlin + Swift) | React Native | Kotlin Multiplatform |
|---|---|---|---|---|
| Wspólny kod Android i iOS | interfejs i logika | brak - dwie osobne aplikacje | interfejs i logika | logika; interfejs wspólny opcjonalnie |
| Język | Dart | Kotlin i Swift | JavaScript / TypeScript | Kotlin (+ Swift w części iOS) |
| Interfejs | własny silnik, ten sam wygląd na obu platformach | natywne komponenty każdej platformy | natywne komponenty sterowane z JavaScriptu | natywny albo Compose Multiplatform |
| Funkcje sprzętowe | przez wtyczki i kanały platformowe | pełny dostęp od razu | przez moduły natywne | pełny dostęp w części natywnej |
| Koszt budowy dwóch platform | najniższy - interfejs i logika pisane raz | najwyższy - dwie osobne aplikacje | niski, zbliżony do Fluttera | średni - przy natywnym interfejsie ekrany powstają dwa razy |
| Kiedy wybieramy | większość aplikacji biznesowych na dwie platformy | sprzęt, praca w tle, wieloletni rozwój | zespół klienta pracuje w React | istniejąca aplikacja w Kotlinie ma dostać wersję na iOS |
Oszczędność we Flutterze bierze się z tego, że interfejs i logikę piszemy raz dla obu platform. W studiach przypadków publikowanych przez Google zespoły Google Classroom i Reflectly raportują skrócenie czasu pracy o co najmniej 50% - to wyniki wybranych wdrożeń, a nie średnia rynkowa.
React Native i Kotlin Multiplatform to dobre narzędzia, ale w naszych projektach wybieramy je rzadziej: pierwszy wtedy, gdy klient ma własny zespół JavaScript, drugi wtedy, gdy rozwija już natywną aplikację na Androida. Szerzej o wyborze technologii piszemy w przewodniku Tworzenie aplikacji Flutter - przewodnik dla klientów.
Jak pracujemy we Flutterze
Wersje i zależności
Pracujemy na stabilnym kanale Fluttera. Wersję SDK i pakietów przypinamy w repozytorium, żeby każda kompilacja dawała ten sam wynik. Aktualizacje Fluttera i wtyczek robimy jako osobne zadanie z testami regresji, a nie przy okazji nowej funkcji.
Architektura
Kod dzielimy według funkcji aplikacji, a w każdej oddzielamy interfejs, logikę i dostęp do danych. Sposób zarządzania stanem wybieramy na początku projektu i zapisujemy w dokumentacji. Funkcje sprzętowe bez sprawdzonej wtyczki piszemy natywnie i podłączamy przez kanały platformowe.
CI/CD i wydania
Każda zmiana uruchamia analizę statyczną, testy i budowę wersji na Androida i iOS. Wersje testowe dostajesz przez TestFlight i ścieżkę testów wewnętrznych Google Play co dwa tygodnie, po zamknięciu etapu. Środowiska testowe i produkcyjne rozdzielamy konfiguracją, a nie ręcznymi zmianami w kodzie.
Testy
Logikę pokrywamy testami jednostkowymi, ekrany testami widgetów, a najważniejsze ścieżki - rejestrację, zamówienie, płatność - testami integracyjnymi. Przed publikacją sprawdzamy aplikację na fizycznych urządzeniach z Androidem i iOS.
Backend do aplikacji we Flutterze budujemy zwykle w Laravelu. Jak wygląda cały projekt od wyceny do publikacji, opisujemy na stronie tworzenie aplikacji mobilnych.
Aplikacje we Flutterze, które zbudowaliśmy
Wszystkie trzy działają na Androidzie i iOS z jednego kodu, z backendem w Laravelu.
Germania Mint: weryfikacja produktów przez NFC przy odbiorze przez kuriera. MASTER Climate Solutions: kalkulatory doboru produktów w 7 językach. Gmina Jarocin: aplikacja dla mieszkańców z e-urzędem, biletami, parkowaniem i płatnościami online.
Dlaczego możesz nam zlecić aplikację we Flutterze
Od 2010 roku na rynku, ponad 300 zrealizowanych projektów
Flutter w realizacjach dla mennicy, gminy, hotelu i producenta klimatyzacji
Backend w Laravelu, w którym powstała większość naszych realizacji
Kod i prawa autorskie przechodzą na Ciebie po zapłacie ostatniej faktury
Najczęściej zadawane pytania o Fluttera
Zaktualizowano: