CV Mobile Developera: React Native, Flutter czy native pod ofertę

Mobile to nie „React, ale na telefon”. Wpisanie w CV „React Native” obok webowego Reacta i nazwanie się mobile developerem to za mało, bo na stanowisku mobilnym rekruter szuka czegoś, czego web nie weryfikuje: aplikacji, która przeszła review w App Store, działa offline w metrze, nie wysypuje się na połowie modeli z Androida i startuje w sekundę, a nie w pięć.

Oferta mobile, niezależnie czy mówi o React Native, Flutterze, czy native, chce zobaczyć jedno: że wypuszczałeś aplikacje na produkcję i są w sklepie. Publikacja w App Store i Google Play to nie detal w stopce CV, tylko dowód, że ogarniasz cały cykl, od kodu przez podpisy i metadane po review, którego web developer nigdy nie dotknął. Kandydat z appką, która ma realne pobrania i ocenę, jest w innej lidze niż ten, który „robił aplikacje mobilne” bez ani jednego linku do sklepu.

Poniżej masz, co wyeksponować nad fold, jak ustawić akcent cross-platform kontra native pod ofertę i jak opisać projekt mobilny przez wpływ: pobrania, ocena, crash-free, czas startu, rozmiar aplikacji.

Co wyeksponować nad fold: framework, platformy, publikacja

„Nad fold” to ta część CV, którą rekruter widzi bez przewijania. Pod ofertę mobilną mają tam być widać trzy rzeczy: czym budujesz, na jakie platformy i że twoje aplikacje są w sklepie. To rdzeń roli, reszta jest wsparciem. Ułóż umiejętności w kolejności istotności dla oferty, nie alfabetycznie:

• Rdzeń: framework z oferty (React Native, Flutter, albo native: Kotlin / Jetpack Compose, Swift / SwiftUI), platformy docelowe (iOS, Android), publikacja w App Store i Google Play.
• Realne wsparcie: zarządzanie stanem (Redux, Riverpod, Bloc), integracje natywne (kamera, push, geolokalizacja, biometria), offline i storage lokalny, testy, CI mobilny (Fastlane, EAS, Codemagic).
• Reszta: narzędzia analityczne, monitoring (Crashlytics, Sentry), narzędzia buildowe, niżej i mniejszą wagą.

Jeśli oferta wymienia konkretną platformę albo framework, którego realnie używasz, ma być widoczny od razu, nie zakopany na trzydziestej pozycji. Rekruter mobile skanuje pod kątem zgodności z ogłoszeniem, nie kompletności kariery. I jeden sygnał, którego web nie ma: link do aplikacji w sklepie robi więcej niż dziesięć logotypów obok siebie.

Cross-platform czy native: dopasuj do oferty

To pierwsza decyzja, którą rekruter chce zobaczyć w kontekście, a nie jako wpisany odruchowo zestaw. Jedna oferta szuka kogoś, kto jednym kodem w React Native albo Flutterze dowiezie iOS i Androida naraz, bo zespół jest mały. Druga, równie często, szuka native dewelopera w Kotlinie albo Swifcie, bo aplikacja jest ciężka, mocno korzysta z natywnych API i każda milisekunda przy starcie się liczy.

Czytaj, czego naprawdę chce ogłoszenie. Jeśli pada „cross-platform”, „jeden codebase na dwie platformy”, eksponuj projekt, w którym jednym kodem obsłużyłeś iOS i Android, i pokaż, co to dało: ile czasu zaoszczędziłeś przy wydaniu na obie platformy. Jeśli oferta mówi o „native”, „Kotlin”, „Swift”, „wydajności”, „złożonych integracjach sprzętowych”, nie udawaj, że cross-platform załatwia wszystko. Pokaż, że schodzisz do natywnego kodu, gdy trzeba: własny moduł natywny, optymalizacja renderowania, praca z API systemu.

W obu przypadkach liczy się ta sama mechanika: nie nazwa technologii, tylko decyzja, jej skala i efekt. Jeden projekt zwykle daje materiał na kilka odcieni tej samej roli: mobile produktowy, integracyjny, wydajnościowy. To ten sam projekt, inny pierwszy plan, bez przepisywania historii. Mechanikę pokazujemy w jeden projekt, cztery role.

Jak opisać projekt mobilny efektem, nie zadaniem

To jest miejsce, gdzie większość CV mobile dewelopera się wykłada. Ludzie wypisują, co robili („tworzyłem ekrany w React Native”, „integrowałem push notyfikacje”), a to są obowiązki, nie dokonania. Nie widać skali aplikacji ani tego, czy po twojej robocie cokolwiek działało lepiej. Pokaż zmianę i jej efekt, mierzony tym, co na mobile się liczy: liczba pobrań, ocena w sklepie, crash-free users, czas startu, rozmiar aplikacji.

Słaby zapis, który czyta się jak zakres obowiązków:

Tworzyłem ekrany w React Native i zajmowałem się integracją powiadomień push oraz trybem offline.

Ten sam fakt, ustawiony pod ofertę mobilną:

Zbudowałem tryb offline w aplikacji React Native z synchronizacją w tle (50 tys. aktywnych użytkowników), co podniosło crash-free users z 97,2% do 99,4% i skróciło czas zimnego startu z 3,1 s do 1,2 s. Aplikacja utrzymała ocenę 4,6 w Google Play po 80 tys. pobrań.

Druga wersja opisuje to samo, co robiłeś, ale pokazuje punkt wyjścia, zmianę i efekt w liczbach. Widać skalę (50 tys. użytkowników, 80 tys. pobrań), zmianę (offline z synchronizacją w tle) i wpływ (crash-free z 97,2% do 99,4%, start z 3,1 s do 1,2 s). To odróżnia kogoś, kto sklejał ekrany z tutoriala, od kogoś, kto rozumie, gdzie aplikacja mobilna traci użytkowników: na crashu, długim starcie i braku reakcji bez sieci.

Mocne akcenty pod mobile i ich konkrety: dystrybucja (pobrania, instalacje, aktywni użytkownicy), jakość (ocena w sklepie, crash-free users w procentach), wydajność (czas zimnego startu, czas do interakcji, płynność listy w fps), rozmiar (waga aplikacji w MB po optymalizacji), zasięg (liczba obsłużonych modeli i wersji systemu).

Słowa kluczowe z ofert mobile

Oferty mobilne powtarzają konkretny zestaw zwrotów, inny dla cross-platform i inny dla native. Cross-platform: react native, flutter, dart, expo, redux albo riverpod, rest api, app store, google play, push notifications, ci/cd mobilny. Native: kotlin, jetpack compose, swift, swiftui, coroutines, mvvm, room albo core data, retrofit. Do tego zwroty wspólne: offline, integracje natywne, crashlytics albo sentry, publikacja. To są twoje słowa kluczowe. Wyciągnij must-have z konkretnej oferty i sprawdź, które masz pokryte realnym przykładem z opublikowanej aplikacji, a których lepiej nie wpisywać, bo zweryfikują je na rozmowie technicznej w pięć minut. Jak czytać ogłoszenie pod tym kątem, rozkładamy w jak wyciągnąć słowa kluczowe z oferty IT.

Jeśli aplikujesz też na role webowe albo schodzisz z fullstacka do mobile, akcent stawiasz inaczej niż na froncie. Jak ustawić React mobilny obok webowego, nie myląc rekrutera, rozkładamy w CV React / Frontend Developera.

Częste błędy

• Aplikacja bez śladu w sklepie. „Robiłem aplikacje mobilne” bez linku, pobrań i oceny to deklaracja, nie dowód. Dodaj, że appka jest w App Store albo Google Play, i podaj metrykę. Opublikowana aplikacja z oceną 4,5 bije pięć projektów „w trakcie”.
• Brak metryk mobilnych. „Optymalizowałem wydajność” bez liczb jest puste. Crash-free z 96% do 99,5%, start z 4 s do 1,5 s, rozmiar z 80 MB do 35 MB to konkret. Bez liczby to puste słowo.
• Cross-platform jako zasłona. Wpisanie tylko „React Native” tam, gdzie oferta pyta o natywne moduły i wydajność, wychodzi na pierwszym pytaniu o most natywny. Pokaż, że schodzisz do native, gdy trzeba, albo nie aplikuj na czysto natywną rolę bez tego doświadczenia.

Jak złożyć CV mobile w ZłóżCV

Pod ofertę mobilną ZłóżCV bierze z twojej bazy projekty, w których realnie wypuszczałeś aplikacje do sklepu, ogarniałeś offline, integracje natywne i wydajność, układa stack pod wymagania ogłoszenia (cross-platform albo native) i przepisuje opisy tak, żeby było widać pobrania, ocenę, crash-free i czas startu, a nie samą listę SDK. Wklejasz link do oferty, dostajesz dopasowane CV w PDF. Złóż CV pod ofertę mobile, dwa pierwsze za darmo, bez karty.

Najczęstsze pytania

React Native, Flutter czy native: co lepiej wygląda w CV? Żadne nie wygląda lepiej w próżni. Liczy się zgodność z ofertą. Pod ofertę cross-platform eksponuj React Native albo Flutter, pod native Kotlin albo Swift. Jeśli masz oba, na pierwszym planie ustaw ten, którego chce ogłoszenie, a drugi pokaż jako kontekst.

Nie mam aplikacji w sklepie, tylko pet-projekty, co wtedy? Opublikuj choć jeden pet-projekt w Google Play. Konto deweloperskie kosztuje jednorazowo, review na Androidzie jest szybkie, a samo przejście przez publikację, podpisy i metadane jest sygnałem, którego brak u kandydatów „w trakcie”. Nawet appka z setką pobrań i oceną 4,8 pokazuje, że ogarniasz cały cykl.

Jak pokazać wydajność, gdy nie mierzyłem dokładnych liczb? Podaj rzędy wielkości, które pamiętasz, zamiast zmyślać precyzję. „Start z kilku sekund do około sekundy”, „crash-free powyżej 99%”, „dziesiątki tysięcy pobrań” jest wiarygodne i konkretniejsze niż „poprawiłem wydajność”. Lepszy uczciwy rząd wielkości niż liczba, której nie obronisz na rozmowie.

Wpisywać native do CV, gdy robiłem głównie React Native? Tylko jeśli realnie pisałeś moduły natywne albo schodziłeś do Kotlina i Swifta. Jeśli twój kontakt z native to jedna konfiguracja w Xcode, nie rób z siebie native dewelopera, bo pytanie o cykl życia aktywności wyłoży to w minutę. Pokaż za to, gdzie cross-platform musiał dotknąć warstwy natywnej.