Dla większości aplikacji biznesowych na iOS i Androida rozsądnym wyborem w 2026 roku jest technologia wieloplatformowa, potocznie nazywana hybrydową: Flutter albo React Native. Aplikacje natywne w Swifcie i Kotlinie opłacają się, gdy produkt opiera się na możliwościach sprzętu albo firma ma już dwa zespoły natywne. Kotlin Multiplatform pasuje do firm z istniejącą aplikacją na Androida, a PWA do narzędzi wewnętrznych, które nie potrzebują sklepu z aplikacjami. O wyborze decydują zespół, istniejący kod i koszt utrzymania przez kilka lat, a nie ranking popularności.
Jakie technologie są do wyboru w 2026 roku?
| Podejście | Język | Jak powstaje interfejs | Liczba baz kodu |
|---|---|---|---|
| Natywne | Swift (iOS), Kotlin (Android) | Narzędzia producenta platformy | Dwie |
| Flutter | Dart | Własny silnik rysujący Impeller | Jedna |
| React Native | JavaScript lub TypeScript | Natywne komponenty platformy sterowane z JavaScriptu | Jedna |
| Kotlin Multiplatform | Kotlin | Natywny osobno na każdej platformie albo wspólny w Compose Multiplatform | Wspólna logika, interfejs do wyboru |
| PWA | JavaScript lub TypeScript | Strona internetowa instalowana na ekranie głównym | Jedna, wspólna z wersją webową |
Stan każdej z nich warto sprawdzić w dokumentacji, bo opinie sprzed kilku lat są nieaktualne. Trzy przykłady:
- Flutter nie jest już nową technologią o niepewnej przyszłości. Według dokumentacji Fluttera kod w Darcie jest w wydaniu produkcyjnym kompilowany z wyprzedzeniem (AOT) do kodu maszynowego zarówno na iOS, jak i na Androidzie. Maszyna wirtualna Darta działa tylko w trybie deweloperskim i umożliwia hot reload, czyli podgląd zmian w działającej aplikacji bez ponownej kompilacji.
- React Native zmienił architekturę. Od wersji 0.76 Nowa Architektura jest włączona domyślnie i zastępuje asynchroniczny most między JavaScriptem a kodem natywnym bezpośrednim interfejsem JSI. Zarzuty o wydajność oparte na starszych wersjach wymagają ponownego sprawdzenia.
- Kotlin Multiplatform ma według dokumentacji JetBrains status stabilny na Androidzie i iOS. Stabilny jest też Compose Multiplatform, czyli wspólny interfejs dla obu platform. Wersja webowa oparta na Kotlin/Wasm pozostaje w fazie beta.
Kiedy aplikacje natywne są warte dwóch baz kodu?
Dwie aplikacje natywne oznaczają dwa zespoły, dwa harmonogramy i każdą funkcję zbudowaną dwa razy. Ten koszt ma uzasadnienie w trzech sytuacjach:
- produkt opiera się na możliwościach urządzenia: przetwarzaniu obrazu z kamery w czasie rzeczywistym, pracy w tle, łączności z urządzeniami medycznymi lub przemysłowymi przez Bluetooth, rozszerzeniach systemowych i widżetach,
- nowe funkcje systemu muszą trafić do aplikacji w dniu premiery iOS albo Androida, bez czekania na wsparcie we frameworku,
- firma ma już dwa zespoły natywne i działający kod, a przepisanie kosztowałoby więcej niż dalszy rozwój.
Sama „wydajność” rzadko jest dziś argumentem. Aplikacja z formularzami, listami, płatnościami i powiadomieniami działa płynnie w każdej z opisanych technologii.
Flutter czy React Native?
Obie technologie dają jedną bazę kodu na iOS i Androida. Różnią się tym, kto łatwiej w nie wejdzie i jak zachowuje się interfejs.
| Kryterium | Flutter | React Native |
|---|---|---|
| Zespół, który wejdzie najszybciej | Programiści mobilni i backendowi, Dart przypomina Javę i Kotlina | Zespół webowy znający Reacta i TypeScript |
| Interfejs | Rysowany przez silnik Fluttera, identyczny na obu platformach | Złożony z natywnych komponentów, bliższy wyglądowi systemu |
| Wspólny kod z aplikacją webową | Flutter obsługuje też web i desktop | Wspólna logika i biblioteki z aplikacją w React |
| Typowe ryzyko | Dart jest rzadszy na rynku pracy niż JavaScript | Zależność od wielu zewnętrznych bibliotek o różnej jakości utrzymania |
Jeśli firma rozwija produkt webowy w React i ma kilkunastu programistów frontendowych, React Native skraca wdrożenie zespołu. Jeśli interfejs ma być mocno własny, z niestandardowymi animacjami i identycznym wyglądem na obu platformach, mniej pracy wymaga Flutter.
Dla kogo jest Kotlin Multiplatform?
Dla firm, które mają aplikację na Androida napisaną w Kotlinie i chcą przestać pisać logikę biznesową dwa razy. Kotlin Multiplatform pozwala przenieść do wspólnego modułu reguły, obsługę sieci i dane, a interfejs zostawić natywny na każdej platformie. Migrację robi się etapami, moduł po module, bez wstrzymywania rozwoju.
Koszt: zespół iOS musi pracować z kodem w Kotlinie i narzędziami JetBrains. W firmie bez kompetencji androidowych ta technologia nie ma przewagi nad Flutterem i React Native.
Kiedy wystarczy PWA?
PWA, czyli aplikacja webowa instalowana na ekranie głównym telefonu, wystarcza narzędziom wewnętrznym, panelom dla partnerów i produktom, w których telefon jest dodatkiem do wersji przeglądarkowej. Nie wymaga procesu publikacji w sklepach ani osobnego zespołu. Przy takich narzędziach osobną decyzją jest wybór między no-code, low-code a kodem od zera.
Ograniczenia widać na iOS. Jak opisuje dokumentacja MDN, instalacja odbywa się tam przez menu Udostępnij, a w przeglądarkach innych niż Safari jest możliwa dopiero od iOS 16.4. Użytkownik nie znajdzie też aplikacji w App Store, chyba że zostanie ona osobno spakowana i zgłoszona do sklepu. W produkcie dla klientów, w którym instalacja ma być oczywista, to realna bariera.
Jak podjąć decyzję w firmie z istniejącym produktem?
Punkt wyjścia to stan obecny, a nie lista zalet frameworków.
| Sytuacja | Kierunek | Dlaczego |
|---|---|---|
| Produkt webowy w React, brak zespołu mobilnego | React Native | Te same osoby i ten sam język, wspólne biblioteki |
| Brak aplikacji i zespołu mobilnego, interfejs mocno własny | Flutter | Jedna baza kodu i pełna kontrola nad wyglądem |
| Dojrzała aplikacja na Androida w Kotlinie, iOS do zbudowania lub utrzymywany osobno | Kotlin Multiplatform | Wspólna logika bez przepisywania interfejsu |
| Dwa zespoły natywne i działające aplikacje | Pozostać przy natywnych | Przepisanie nie zwróci się, jeśli tempo rozwoju jest wystarczające |
| Integracja z urządzeniem medycznym, praca w tle, zaawansowana kamera | Natywne albo wieloplatformowe z modułami natywnymi | Krytyczna część i tak powstaje w kodzie platformy |
| Narzędzie wewnętrzne dla pracowników | PWA | Bez publikacji w sklepach i bez dodatkowego kodu do utrzymania |
Technologia wpływa na budżet mniej niż zakres funkcji. Widełki i przykładowy kosztorys podajemy we wpisie o tym, ile kosztuje stworzenie aplikacji mobilnej. Decyzję techniczną, którą trzeba będzie uzasadnić przed zarządem, można zweryfikować z kimś spoza zespołu na konsultacji, zanim powstanie pierwsza linia kodu.
Co najczęściej idzie źle przy wyborze technologii?
- Wybór pod zespół, którego firma nie ma. Technologia dobrana do preferencji jednego wykonawcy zostaje w firmie na lata. Przed decyzją trzeba sprawdzić, kto będzie rozwijał aplikację po wdrożeniu i czy takich osób da się zatrudnić.
- Pominięcie kosztu utrzymania. Apple i Google wydają co roku nowe wersje systemów i zmieniają wymagania sklepów. Każda technologia wymaga aktualizacji, a w wieloplatformowej dochodzi aktualizacja frameworka i bibliotek.
- Założenie, że jedna baza kodu oznacza zero kodu natywnego. Płatności, logowanie biometryczne, powiadomienia i integracje ze sprzętem korzystają z wtyczek. Gdy wtyczki brakuje albo jest porzucona, ktoś musi napisać moduł w Swifcie i Kotlinie.
- Przepisywanie działającej aplikacji bez policzenia zwrotu. Przez kilka miesięcy zespół odtwarza istniejące funkcje zamiast budować nowe. Migracja ma sens, gdy obecny kod blokuje rozwój, a nie dlatego, że pojawiła się nowsza technologia.
- Projekt interfejsu oderwany od technologii. Ekrany zaprojektowane bez wiedzy o tym, co framework daje gotowe, a co trzeba budować od zera, podnoszą koszt wdrożenia. Kolejność prac opisujemy we wpisie o etapach budowy aplikacji mobilnej na zamówienie.
Jak pracujemy w Squares
Aplikacje mobilne budujemy we Flutterze, więc ten wybór znamy najlepiej, także od strony utrzymania. Gdy z analizy wynika, że produkt wymaga aplikacji natywnych albo PWA, mówimy to przed wyceną. Wdrożenie zaczyna się od 20 000 zł netto i jest wyceniane z góry albo rozliczane za przepracowany czas. Etapy pracy pokazuje wpis o tym, jak wygląda proces wdrażania oprogramowania.
Najczęstsze pytania
Czy Flutter jest wolniejszy od aplikacji natywnej?
W typowej aplikacji biznesowej różnica nie jest odczuwalna. Kod Fluttera w wydaniu produkcyjnym jest kompilowany z wyprzedzeniem do kodu maszynowego na iOS i Androidzie, a interfejs rysuje silnik Impeller. Przewaga aplikacji natywnych pojawia się w zadaniach mocno związanych ze sprzętem, na przykład przy przetwarzaniu obrazu z kamery w czasie rzeczywistym.
Czy React Native nadal ma problemy z wydajnością?
Zarzuty dotyczyły głównie asynchronicznego mostu między JavaScriptem a kodem natywnym. Od wersji 0.76 React Native domyślnie używa Nowej Architektury, w której most zastąpił interfejs JSI. Opinie i pomiary sprzed tej zmiany nie opisują już obecnego stanu technologii, więc wydajność należy oceniać na aktualnej wersji i na własnym, konkretnym przypadku użycia.
Kiedy warto przepisać aplikację na inną technologię?
Gdy obecny kod blokuje rozwój: brakuje osób do utrzymania, każda funkcja powstaje dwa razy albo framework nie jest już wspierany. Sama dostępność nowszej technologii nie wystarcza, bo przez kilka miesięcy zespół odtwarza istniejące funkcje. Mniejszym ryzykiem jest migracja etapami, na przykład przeniesienie wspólnej logiki do Kotlin Multiplatform.
Czy PWA może zastąpić aplikację mobilną?
W narzędziach wewnętrznych i panelach dla partnerów tak, bo użytkownicy dostają instrukcję instalacji, a firma nie utrzymuje osobnego kodu. W produkcie dla klientów PWA przegrywa na iOS: instalacja wymaga użycia menu Udostępnij, a aplikacji nie ma w App Store, dopóki nie zostanie osobno spakowana i zgłoszona do sklepu.
