Jak ocenić umiejętności programistę mobilnego?

Czego szukamy w Senior Mobile developera

Rynek mobile w 2026 roku jest fragmentaryczny jak nigdy. Klient potrzebuje aplikacji iOS w Swift 5.9 z SwiftUI i Swift Concurrency, równolegle Androida w Kotlinie 2.0 z Jetpack Compose, a coraz częściej obu z jednego codebase’u poprzez Kotlin Multiplatform Mobile (KMM), Flutter 3.x lub React Native z New Architecture (Fabric + TurboModules). Senior Mobile developer musi sprawnie poruszać się przynajmniej po dwóch z tych światów oraz znać kompromisy każdego z nich — kiedy warto pisać natywnie, kiedy KMM dzieli logikę biznesową przy zachowaniu natywnego UI, a kiedy Flutter daje wystarczające 95% jakości przy 60% kosztu. To również osoba rozumiejąca cały lifecycle aplikacji: code signing, provisioning profiles, App Store Connect, Google Play Console, beta testy przez TestFlight i Internal Testing, polityki sklepów (App Tracking Transparency, Data Safety) oraz proces review.

W ARDURA Consulting weryfikujemy także świadomość operacyjną. Senior Mobile to ktoś, kto potrafi zbudować pipeline CI/CD w Fastlane, Bitrise lub Codemagic, podpisać builda kluczem z keychain, dostarczyć go automatycznie do TestFlight i Firebase App Distribution, a w razie crashu odczytać symbolicate’owany stack trace w Crashlytics lub Sentry. Musi rozumieć push notifications na obu platformach (APNs z certyfikatami p8, FCM przez tokeny), polityki tła (BGTaskScheduler w iOS, WorkManager w Androidzie), warstwy persystencji (Core Data, SwiftData, Realm po stronie iOS; Room z Hilt po stronie Androida) oraz świadomie sięgać po Combine, Coroutines i Flow zamiast callbacków. Szukamy też dojrzałości w testowaniu — XCTest i Quick/Nimble na iOS, JUnit 5 i Espresso na Androidzie, ewentualnie Maestro lub Detox dla cross-platform E2E.

Top 15 pytań rekrutacyjnych z odpowiedziami

1. Czym różni się Swift Concurrency od GCD i kiedy używamy Task vs DispatchQueue? Swift Concurrency to model strukturalny z async/await, actor, Task i TaskGroup. Eliminuje większość race conditions kompilatorowo (Sendable). GCD to stary, callbackowy model — wciąż użyteczny w legacy lub przy interop z UIKit. Nowe projekty: Swift Concurrency. Senior wspomni o izolacji @MainActor.

2. Czym jest Jetpack Compose i jak różni się od systemu View? Deklaratywny framework UI dla Androida, oparty na Kotlinie i Coroutines. Stan zarządzany przez remember, mutableStateOf, StateFlow. Recomposition zamiast invalidacji View. Senior wskaże na konieczność rozumienia stability i skippable functions oraz różnicy między LaunchedEffect a DisposableEffect.

3. Co to jest Kotlin Multiplatform Mobile i jakie są jego ograniczenia? KMM pozwala dzielić logikę biznesową (modele, network, repositories) między iOS i Android, zostawiając UI natywne. Ograniczenia: ekosystem bibliotek wciąż mniejszy niż czysty Kotlin/Swift, debug w XCode iOS bywa bolesny, kompilacja do framework’a iOS dodaje narzut do build time.

4. Jak działa New Architecture w React Native (Fabric + TurboModules)? Fabric to nowy renderer napisany w C++, działający synchronicznie i z mniejszym narzutem komunikacji JS-native. TurboModules to lazy-loading natywnych modułów z type-safe interfejsem przez Codegen. Razem eliminują bridge i bottlenecki znane z dawnego RN.

5. Co to jest Combine i kiedy używasz Publisher vs AsyncSequence? Combine to reaktywny framework Apple’a (Publisher, Subscriber, operators). AsyncSequence to natywny strumień asynchroniczny w Swift Concurrency. Dla nowego kodu coraz częściej preferujemy AsyncSequence; Combine wciąż dominuje w warstwach networking i przy SwiftUI w wielu projektach.

6. Czym różni się StateFlow od SharedFlow w Kotlinie? StateFlow to hot stream z aktualnym stanem (conflated). SharedFlow jest bardziej elastyczny — można konfigurować replay cache i extra buffer. UI state → StateFlow. Eventy jednorazowe → SharedFlow z replay=0.

7. Jak zarządzać dependency injection w Androidzie z Hilt? Hilt to warstwa na Daggerze dla Androida. Definiujemy moduły (@Module, @InstallIn(SingletonComponent::class)), wstrzykujemy do ViewModeli (@HiltViewModel). Senior porówna z Koinem (lekki, runtime) i wskaże, kiedy Hilt jest overkillem.

8. Co to jest SwiftData i czym różni się od Core Data? SwiftData (iOS 17+) to nowoczesna warstwa persystencji oparta o macro @Model, zintegrowana z SwiftUI i Swift Concurrency. Pod spodem nadal Core Data. Mniej boilerplate’u, ale w bardziej skomplikowanych modelach (migracje, NSPersistentCloudKitContainer) Core Data daje więcej kontroli.

9. Jak podpisać i wypuścić aplikację iOS automatycznie przez Fastlane? fastlane match synchronizuje certyfikaty i provisioning profiles z repo (lub App Store Connect API). gym buduje, pilot wysyła do TestFlight, deliver do App Store. Senior wymieni też przejście z certyfikatów p12 na App Store Connect API key (JWT).

10. Co to jest App Tracking Transparency i jak wpływa na analytics? Polityka iOS wymagająca explicit user consent na śledzenie cross-app (IDFA). Bez zgody analytics tracking jest bardzo ograniczony — sięgamy po SKAdNetwork i agregowane metryki. Senior wspomni o consent management platforms.

11. Czym różni się Retrofit od Ktor jako klient HTTP? Retrofit to ustabilizowany standard Androida (annotation processing, integracja z OkHttp). Ktor to nowsza biblioteka Kotlin Multiplatform — działa też w KMM, bardziej kompozycyjna (engines, plugins), świetna w projektach Compose Multiplatform.

12. Jak diagnozować crash w produkcji? Crashlytics lub Sentry — symbolicated stack trace, breadcrumbs, custom keys. Senior pokaże flow: znaleźć crash → odtworzyć lokalnie → napisać test regresyjny → wypuścić hotfix przez TestFlight/Internal Testing.

13. Jak działa MAUI i kiedy warto go rozważyć? .NET MAUI to następca Xamarin.Forms, single project dla iOS, Android, Windows, macOS w C#. Dobry wybór dla zespołów .NET-owych i aplikacji enterprise. Senior wskaże ograniczenia performance’owe i mniejszą społeczność open source vs Flutter/RN.

14. Co to są push notifications i czym różnią się APNs od FCM? APNs (Apple) — token-based przez p8 key. FCM (Google) — abstrakcja Firebase ponad systemowymi tokenami Androida (i może też wysyłać do APNs). Senior opisze różnicę między alert, background i silent notifications oraz politykę tła.

15. Jak budować cross-platform UI w Compose Multiplatform? JetBrains Compose Multiplatform pozwala dzielić nie tylko logikę (jak KMM), ale i UI Compose między Android, iOS, Desktop. Senior wskaże, że iOS support jest jeszcze stabilizowany i że dla dużych projektów warto trzymać native UI.

Zadania techniczne — 3 scenariusze

Scenariusz 1 — SwiftUI z paginacją i offline cache. Kandydat dostaje listę produktów do wyświetlenia w SwiftUI z paginacją (infinite scroll), stanem ładowania, obsługą błędów i offline cache w Core Data lub SwiftData. Wymagamy użycia Swift Concurrency (async/await, Task), izolacji UI updates przez @MainActor, jednostkowych testów ViewModeli z XCTest. Oceniamy podział na warstwy (View → ViewModel → Repository → Network/Cache), poprawność cancellation przy zmianie ekranu, czystość kodu. Senior pokaże świadomość Sendable i unikania capture self w długich Taskach.

Scenariusz 2 — Jetpack Compose z formularzem i walidacją. Zadanie: napisać ekran rejestracji w Jetpack Compose z walidacją na żywo (email, hasło, regulamin), state hoistingiem, integracją z ViewModel używającym StateFlow, network callem przez Retrofit, obsługą błędów (Snackbar) i testem instrumentalnym przez Compose Test Rule. Oceniamy świadomość recomposition (stability), separację state holdera od kompozytów, użycie Coroutines i Flow zamiast LiveData. Senior zaproponuje też modularizację (feature module, design system).

Scenariusz 3 — Cross-platform z Flutter lub KMM. Dla kandydatów Flutterowych: zbudować szybką aplikację z BLoC pattern (lub Riverpod), Firebase Auth, listą ulubionych w Hive lub Isar, light/dark theme switcherem, CI/CD przez Codemagic. Dla kandydatów KMM: dzielona warstwa Ktor + SQLDelight + ViewModel napisany w commonMain, natywne UI w SwiftUI i Jetpack Compose. Oceniamy świadomość kompromisów cross-platform, jakość obsługi błędów sieci, testowalność dzielonej logiki.

Red flags

Czerwona lampka zapala się, gdy kandydat pisze nową aplikację iOS w UIKit „bo SwiftUI jeszcze nie gotowy” bez konkretnych argumentów (constraint klienta, integracja z biblioteką tylko-UIKit, performance widoku z 10k komórek). Podobnie po stronie Androida — uparcie trzymanie się systemu View bez planu migracji do Compose. Drugi sygnał to nieznajomość zarządzania zależnościami (kandydat nie wie, czym jest SwiftPM, CocoaPods, Gradle Version Catalog) i nieumiejętność rozwiązania konfliktu wersji bibliotek. Dalej: zero doświadczenia z code signingiem i provisioning profiles, brak rozumienia App Tracking Transparency i Data Safety, ignorowanie offline-first (każde wczytanie idzie do sieci), brak testów. Czerwona flaga to też nieumiejętność opisania crash flow — jak diagnozuje, jak symbolicate’uje, jak wypuszcza hotfix. I wreszcie: brak doświadczenia z release cycle’ami sklepów (rejection, expedited review, gradual rollout w Google Play).

Jak ARDURA Consulting weryfikuje kandydatów

W ARDURA Consulting prowadzimy trzyetapową weryfikację Senior Mobile developera w 5 dni roboczych. Etap pierwszy — rozmowa techniczna ze specjalistą po stronie platformy (iOS lub Android), kalibrowana do stacka klienta (Swift+SwiftUI, Kotlin+Compose, Flutter, RN, KMM). Etap drugi — zadanie praktyczne (live coding 90 minut lub take-home na 4-6 godzin), gdzie oceniamy strukturę kodu, świadomość lifecycle’u, testowalność, obsługę edge case’ów. Etap trzeci — rozmowa kulturowa z klientem i weryfikacja procesu release (CI/CD, code signing, distribution).

W naszej bazie mamy specjalistów po każdej stronie stacka — natywnych iOS-owców pracujących w Swift od czasów Objective-C, Android engineerów którzy migrowali zespoły z View na Compose, fluterowców z aplikacjami w 1M+ pobraniach i RN-owców znających New Architecture od dnia jej zapowiedzi. Każdy z nich ma potwierdzone wdrożenia w App Store i Google Play, a w portfolio doświadczenie z code signingiem, certyfikatami, push notifications i procesem review. Sprawdzamy też doświadczenie z Crashlytics i Sentry — każdy senior musi pokazać, jak diagnozował realny crash w produkcji i jak wypuszczał hotfix przez Expedited Review lub Staged Rollout.

Dzięki bazie ponad 500 sprawdzonych seniorów IT i 99% retencji prezentujemy 2-3 dopasowanych kandydatów w 14 dni, z dwutygodniowym onboardingiem na projekt. Średnia oszczędność klienta na pełnym procesie rekrutacyjnym vs in-house — 40%. Współpracujemy zarówno z firmami szukającymi pojedynczego eksperta na 3-6 miesięcy, jak i ze startupami budującymi pełen dedykowany zespół iOS + Android + QA. Sprawdź dostępnych ekspertów →