Lynx - nowa alternatywa dla React Native?

Kiedy w marcu 2025 roku ByteDance udostępnił jako open source swój framework Lynx, w branży szybko przylgnęło do niego krótkie określenie: „React Native od TikToka". Brzmi atrakcyjnie, zwłaszcza dla firm, które mają albo planują aplikację mobilną. Lynx - nowa alternatywa dla React Native? Na to pytanie nie ma jednej odpowiedzi „tak" albo „nie", bo Lynx rozwiązuje trochę inny problem, niż sugerują nagłówki.

React Native od lat jest jedną z dwóch najpopularniejszych dróg do aplikacji na iOS i Androida z jednego kodu, zamiast aplikacji natywnych pisanych osobno dla każdej platformy. Drugą jest Flutter. Lynx wchodzi na ten rynek z dużym zapleczem i dobrymi wynikami wydajności. Ma też jedno ograniczenie, które dla wielu firm przesądza sprawę.

Lynx - nowa alternatywa dla React Native z zaplecza TikToka

Lynx to framework do budowania interfejsów, które wyświetlają się jako natywne ekrany na telefonie, choć kod pisze się w JavaScripcie lub TypeScripcie. Powstał wewnątrz ByteDance i przez lata służył do budowy części produktów tej firmy. Według wpisu ogłaszającego otwarcie kodu działają na nim między innymi panel wyszukiwania w TikToku, aplikacja TikTok Studio, sklepy w TikTok Shop i fragmenty transmisji LIVE. Kod jest dostępny na licencji Apache 2.0, więc można go używać komercyjnie bez opłat. Projekt rozwija się szybko. Wersja 4.0 ukazała się 30 września 2026 roku i dodała między innymi obsługę urządzeń składanych, zapytania CSS dopasowujące układ do ekranu oraz natywne efekty rozmycia w stylu iOS (według bloga Lynx). Poza iOS i Androidem Lynx działa też w przeglądarce, na HarmonyOS od Huawei, a od wiosny 2026 roku także na komputerach z macOS i Windows.

Skala społeczności jest na razie nieporównywalna. W październiku 2026 roku repozytorium Lynx miało około 15 tys. gwiazdek na GitHubie, a repozytorium React Native prawie 127 tys. Gwiazdki nie mierzą jakości, ale dobrze pokazują, ilu ludzi zna daną technologię i ile pytań ktoś już przed nami zadał.

Do pisania interfejsu służy ReactLynx, czyli odmiana React.js przystosowana do Lynx. Komponenty i hooki wyglądają znajomo, składnia JSX też. Zmienia się to, co dzieje się pod spodem.

Co Lynx robi inaczej niż React Native

Najważniejsza różnica dotyczy podziału pracy w aplikacji. Lynx świadomie rozdziela ją na dwa wątki, czyli dwa niezależne tory, na których telefon wykonuje kod. Wątek główny odpowiada za rysowanie ekranu i działa na małym, szybkim silniku JavaScript o nazwie PrimJS. Wątek w tle zajmuje się logiką aplikacji, na przykład pobieraniem danych z serwera.

Z tego podziału wynikają dwie cechy, którymi Lynx się chwali. Pierwsza to natychmiastowe wyświetlenie pierwszego ekranu (Instant First-Frame Rendering). Użytkownik nie widzi pustego ekranu ani kręcącego się kółka, bo pierwszy widok powstaje od razu na wątku głównym. Druga to możliwość uruchomienia małych fragmentów kodu bezpośrednio na wątku głównym, co przydaje się przy gestach i animacjach, które muszą reagować na palec bez opóźnienia. React Native też dzieli pracę między wątki, ale programista ma mniej bezpośredniej kontroli nad tym, co gdzie się wykonuje. ByteDance podaje, że przy przenoszeniu ekranów z technologii webowych na Lynx czas uruchamiania spadał od dwóch do czterech razy. To dane producenta z własnych produktów. Rozsądnie traktować je jako kierunek, a nie obietnicę dla każdej aplikacji.

Druga różnica jest bliższa codziennej pracy. Lynx obsługuje prawdziwy CSS, z selektorami, animacjami, gradientami i przejściami. W React Native style zapisuje się w obiektach JavaScript, które tylko przypominają CSS i obsługują jego wybrane fragmenty. Dla zespołu, który na co dzień buduje strony i aplikacje webowe, to realna oszczędność czasu. Mniej trzeba się przestawiać, a część wiedzy o wydajnych animacjach CSS przenosi się wprost.

Do budowania projektu służy Rspeedy, narzędzie oparte na Rspack, szybszym następcy Webpacka. Dla menedżera to szczegół. Dla zespołu oznacza krótsze czekanie na każdą zmianę w kodzie.

Silnik, nie gotowa aplikacja

Tu dochodzimy do ograniczenia, o którym nagłówki zwykle milczą. Lynx nie służy do zbudowania samodzielnej aplikacji od pierwszej do ostatniej linijki. Dokumentacja opisuje go jako wydajny silnik do wyświetlania interfejsu, który osadza się w istniejącej aplikacji: „cross-platform UI rendering engine you can embed anywhere inside your existing application" (dokumentacja Lynx). W praktyce oznacza to, że ktoś musi najpierw przygotować natywną aplikację na iOS i Androida, napisaną w Swifcie i Kotlinie. Do niej dodaje się silnik Lynx, konfiguruje usługi takie jak ładowanie obrazów czy komunikacja z serwerem i dopiero w tak przygotowanych miejscach wyświetla ekrany napisane w ReactLynx. Logowanie, powiadomienia push, płatności, aparat - wszystko, co wymaga dostępu do telefonu, zostaje po stronie natywnej albo trzeba to samodzielnie udostępnić Lynxowi.

React Native działa odwrotnie. Projekt startuje jako aplikacja React Native, a natywny kod dopisuje się tylko wtedy, gdy jest potrzebny. Narzędzia takie jak Expo idą jeszcze dalej i pozwalają zbudować, przetestować i wysłać do sklepów całą aplikację bez otwierania Xcode czy Android Studio. Odpowiednika Expo w świecie Lynx na razie nie ma, na co zwracał uwagę między innymi przegląd pkgpulse z marca 2026 roku.

Ta różnica wyjaśnia, dlaczego Lynx tak dobrze sprawdza się w TikToku. TikTok ma ogromne zespoły iOS i Android, a Lynx pozwala im szybko dokładać i zmieniać ekrany w aplikacji, która już istnieje. Firma, która ma już aplikację natywną, na przykład podobną do aplikacji treningowej Fit Paradise napisanej przez nas w Swifcie i Kotlinie, ma gotowe miejsce, w którym Lynx może działać. Mała firma bez programistów natywnych musiałaby taki szkielet dopiero zbudować.

Ekosystem, czyli ile gotowych klocków dostajesz

Przy wyborze technologii mobilnej mniej liczy się sam framework, a bardziej to, co wokół niego urosło. React Native ma za sobą prawie dekadę bibliotek: nawigację między ekranami, gotowe integracje z Firebase, płatnościami, mapami, analityką, biblioteki do testów automatycznych takie jak Detox. Większość typowych funkcji ktoś już kiedyś zbudował i udostępnił.

W Lynx zestaw gotowych elementów jest znacznie skromniejszy. Są podstawowe komponenty, obsługa gestów, narzędzia do testów i debugowania. Integracje z usługami zewnętrznymi zespół często musi zbudować sam, po stronie natywnej. Każda taka integracja to dni pracy, które w React Native kończą się zwykle instalacją biblioteki i konfiguracją.

Jest też kwestia ludzi. Programistów React Native jest na rynku wielu, specjalistów Lynx bardzo niewielu. Doświadczony programista React szybko odnajdzie się w ReactLynx, ale integracja z natywną aplikacją wymaga kogoś, kto zna iOS i Androida od środka. To wpływa na skład zespołu i na to, jak łatwo będzie go uzupełnić za dwa lata.

Trzy firmy, trzy różne odpowiedzi

Teoria niewiele mówi, dopóki nie przyłoży się jej do konkretnej sytuacji. Poniższe trzy przypadki są uogólnione, ale każdy z nich często pojawia się przy rozmowach o wyborze technologii mobilnej.

Sklep internetowy z działającą aplikacją w React Native

Firma prowadzi sklep z modą i od trzech lat ma aplikację w React Native. Katalog działa, koszyk działa, ale ekran listy produktów przy słabszym telefonie przycina się przy przewijaniu. Ktoś w zespole przeczytał o Lynx.

Tu odpowiedź jest najprostsza: nie przepisywać. Problemy z płynnością list i obrazów w React Native mają znane rozwiązania, od optymalizacji renderowania list po lżejsze obrazy i mniej przerysowań. Przepisanie aplikacji na Lynx oznaczałoby budowę natywnego szkieletu od nowa, czyli projekt dłuższy i droższy niż naprawa jednego ekranu. W branży mody i e-commerce większy zwrot daje zwykle praca nad szybkością sklepu i ścieżką zakupu niż zmiana frameworka.

Przykład z naszych realizacji: aplikację lojalnościową SAO Life, z rezerwacjami, treściami dla członków klubu i płatnościami za członkostwo, zbudowaliśmy w React Native. Przy takim zakresie funkcji dojrzały ekosystem bibliotek ma większe znaczenie niż kilka procent wydajności.

Startup, który zaczyna od zera

Założyciele mają pomysł, budżet na pierwszą wersję i jeden zespół. Potrzebują aplikacji mobilnej na iOS i Androida, z logowaniem, płatnościami i powiadomieniami, najlepiej w kilka miesięcy.

Lynx jest tu złym wyborem, i to nie z powodu jakości. Wymagałby osobno budowy natywnych aplikacji jako „hostów", a potem uzupełniania brakujących integracji. Rozsądniej sięgnąć po React Native z Expo albo po Fluttera. Kryteria wyboru między nimi zbiera porównanie React Native i Fluttera. Pierwsza wersja produktu, czyli MVP, ma przede wszystkim sprawdzić pomysł, a do tego potrzebna jest technologia, przy której zespół nie traci tygodni na infrastrukturę.

Duża aplikacja natywna, która chce szybciej zmieniać ekrany

Trzeci przypadek wygląda inaczej. Firma ma dużą aplikację napisaną natywnie, osobne zespoły iOS i Android oraz kilkanaście ekranów, które często się zmieniają, na przykład promocje i oferty partnerów. Każda zmiana wymaga dziś pracy w dwóch kodach i czekania na publikację nowej wersji w sklepach.

Tu Lynx zaczyna mieć sens. Można osadzić go w istniejącej aplikacji i pisać nowe, często zmieniane ekrany raz, w JavaScripcie i CSS, zamiast dwa razy. Natywne zespoły dalej odpowiadają za fundamenty, a zespół webowy dokłada treść. Tak budowane są super aplikacje, które łączą wiele usług w jednym miejscu, i duże platformy typu marketplace, w których różne części aplikacji rozwijają różne zespoły. Dotychczas firmy w tej sytuacji często sięgały po WebView, czyli osadzoną stronę internetową. Lynx daje podobną elastyczność, ale z natywnymi elementami interfejsu i szybszym pierwszym ekranem.

Jak sprawdzić Lynx bez dużego ryzyka

Jeśli Twoja sytuacja przypomina trzecią firmę, nie ma potrzeby decydować od razu o całej aplikacji. Lepiej przenieść na Lynx jeden ekran, najlepiej taki, który często się zmienia i jest mierzalny, na przykład stronę promocji. Przed rozpoczęciem pilotażu dobrze jest ustalić, co dokładnie zostanie zmierzone:

• czas od otwarcia ekranu do pokazania treści, porównany z obecną wersją,
• płynność przewijania i animacji na tańszym telefonie z Androidem, a nie tylko na najnowszym iPhonie,
• wzrost rozmiaru aplikacji po dodaniu silnika Lynx,
• czas, jaki zespół poświęcił na integrację z natywną częścią aplikacji,
• funkcje, których zabrakło i które trzeba było dopisać samodzielnie.

Takie dane pozwalają podjąć decyzję na podstawie własnej aplikacji, a nie cudzych benchmarków. Przy okazji wychodzi na jaw, ile wiedzy natywnej faktycznie potrzeba w zespole. Jeśli pilot pokaże, że zysk jest niewielki, firma traci jeden ekran pracy, a nie przebudowę całego produktu.

Na etapie decyzji przydaje się spojrzenie z zewnątrz. W ramach usługi mobile development dobieramy technologię do produktu, a nie odwrotnie. Gdy pytań jest więcej niż odpowiedzi, warsztaty product discovery pozwalają przed pierwszą linijką kodu ustalić zakres i rząd wielkości kosztów.

Na co patrzeć w kolejnych miesiącach

Lynx rozwija się w tempie, które trudno zignorować. Między marcem 2025 a wrześniem 2026 roku doczekał się kilku dużych wydań, obsługi HarmonyOS i komputerów oraz własnych narzędzi do testów. Za projektem stoi firma, która używa go we własnych produktach o ogromnym zasięgu, więc ryzyko porzucenia jest mniejsze niż przy wielu młodych frameworkach.

Żeby Lynx stał się realną alternatywą dla React Native w typowym projekcie, musiałoby się jednak zmienić kilka rzeczy. Najważniejsza to możliwość założenia samodzielnej aplikacji bez ręcznego budowania natywnego szkieletu. Do tego dochodzi większy zestaw gotowych integracji i społeczność, w której łatwo znaleźć odpowiedź na nietypowy problem. Obserwujemy to z bliska, bo wybór technologii mobilnej to decyzja o koszcie utrzymania aplikacji na lata, a nie na jeden sezon.

Do tego czasu nasza odpowiedź na pytanie z początku brzmi tak: Lynx jest dziś bardzo dobrym narzędziem dla firm z dużą aplikacją natywną i zespołami po obu stronach. Dla większości pozostałych bezpieczniejszy pozostaje React Native albo Flutter. Jeśli nie wiesz, do której grupy należy Twój projekt, porozmawiajmy o nim.