# Aplikacja na iOS i Androida z jednego kodu w React Native

Strona: https://kontaktio.pl/wiedza/aplikacja-na-ios-i-androida, ostatnia zmiana 2026-10-12

Opublikowano 2026-10-09. Autor: Kontaktio.

Aplikacja z jednego kodu to jeden projekt, na przykład w React Native, z którego powstają wersje na iPhone'a i Androida. Opisujemy Expo, kod natywny na przykładzie AlertMe, testy, przegląd w sklepach i koszt.

## Aplikacja na iOS i Androida jednocześnie

Aplikację na iOS i Androida można zbudować jednocześnie, z jednego projektu, z którego powstaje wersja na iPhone'a i wersja na telefony z Androidem. Każda trafia do swojego sklepu, App Store albo Google Play, skąd użytkownik ją pobiera. Tak budujemy aplikacje na oba systemy, a AlertMe dla agencji ochrony Securand napisaliśmy w React Native.

Dla Ciebie oznacza to jedną listę funkcji, ustalaną na warsztacie, i jeden harmonogram z datami odbiorów, przygotowany przed startem prac. Próg cenowy w naszym cenniku obejmuje jedną aplikację na oba systemy, wydawaną z konta deweloperskiego Twojej firmy w App Store i Google Play. Logowanie, dane i powiadomienia obu wersji działają na jednym zapleczu, wspólnym z panelem administracyjnym.

Jeden kod nie musi oznaczać identycznych ekranów na obu systemach. Według dokumentacji React Native aplikacja na kilka platform korzysta ze wspólnego kodu, ile tylko się da, a tam, gdzie ma to sens, kod rozdziela się według platformy. Można na przykład przygotować osobne komponenty interfejsu dla Androida i dla iOS.

Źródło: [React Native, Platform-Specific Code](https://reactnative.dev/docs/platform-specific-code), dostęp 2026-10-09

## React Native a aplikacja natywna

Aplikacja w React Native wyświetla te same natywne elementy interfejsu co aplikacja pisana osobno dla Androida i dla iOS. Różnica dotyczy kodu, bo wspólne funkcje pisze się w React Native raz dla obu systemów. Dokumentacja projektu przedstawia to jako sposób na wyrównanie funkcji między platformami.

Źródło: [React Native, Get Started with React Native](https://reactnative.dev/docs/environment-setup), dostęp 2026-10-09

React Native to otwarty framework do budowy aplikacji na Androida i iOS z użyciem biblioteki React i natywnych możliwości każdej platformy. Udostępniła go Meta w 2015 roku i od tego czasu go utrzymuje.

Źródło: [React Native, strona projektu](https://reactnative.dev/), dostęp 2026-10-09

Ekrany aplikacji opisuje się w JavaScripcie jako komponenty Reacta. W czasie działania aplikacji React Native tworzy z nich odpowiadające im widoki Androida i iOS, czyli podstawowe elementy interfejsu obu systemów. Komponentowi tekstu odpowiada na Androidzie widok TextView, a na iOS widok UITextView. W aplikacjach pisanych natywnie takie widoki tworzy się w Kotlinie albo Javie na Androida i w Swifcie albo Objective-C na iOS.

Źródło: [React Native, Core Components and Native Components](https://reactnative.dev/docs/intro-react-native-components), dostęp 2026-10-09

## Expo przy budowie i publikacji

Expo to otwarty framework dla aplikacji w React Native, z własnym zestawem modułów, czyli Expo SDK. Jego twórcy prowadzą też usługi chmurowe EAS do budowy aplikacji, wysyłki do sklepów i aktualizacji. Przy nowej aplikacji dokumentacja React Native zaleca framework, na przykład Expo. Expo jest wśród technologii AlertMe i naszej usługi [aplikacji mobilnych](https://kontaktio.pl/aplikacje-mobilne).

Źródło: [Expo Documentation, Core concepts](https://docs.expo.dev/core-concepts/), dostęp 2026-10-09

Źródło: [React Native, Get Started with React Native](https://reactnative.dev/docs/environment-setup), dostęp 2026-10-09

EAS Build kompiluje w chmurze pliki aplikacji na Androida oraz iOS i może sam zarządzać kluczami i certyfikatami do ich podpisu. Do sklepu trafia podpisany plik, w formacie .aab na Androida i .ipa na iOS. EAS Submit wysyła go do Google Play Console albo App Store Connect, czyli do paneli Google i Apple, w których firma zarządza aplikacją.

Źródło: [Expo Documentation, EAS Build](https://docs.expo.dev/build/introduction/), dostęp 2026-10-09

Na Androidzie EAS Submit umieszcza plik na wybranej ścieżce Google Play, testowej albo produkcyjnej, a pierwsze wydanie nowej aplikacji domyślnie na ścieżce testów wewnętrznych. Na iOS plik po przetworzeniu trafia do TestFlight i sam nie przechodzi do App Store. Do przeglądu Apple zgłasza się go w App Store Connect, po uzupełnieniu danych aplikacji i zrzutów ekranu.

Źródło: [Expo Documentation, Submit to app stores](https://docs.expo.dev/deploy/submit-to-app-stores/), dostęp 2026-10-09

## Kiedy potrzebny jest kod natywny

Kod natywny w Kotlinie i Swifcie jest potrzebny wtedy, gdy aplikacja ma korzystać z funkcji systemu, której nie obsługuje React Native ani gotowa biblioteka. Podłącza się go do aplikacji jako moduł natywny. Expo ma do tego własny interfejs, w którym moduły i widoki pisze się właśnie w Swifcie i Kotlinie.

Źródło: [React Native, Native Modules, Introduction](https://reactnative.dev/docs/turbo-native-modules-introduction), dostęp 2026-10-09

Według dokumentacji Expo zwykle nie trzeba pisać kodu natywnego, bo biblioteki obsługują już między innymi aparat, wideo i mapy. Własny moduł bywa potrzebny przy usłudze wymaganej w firmie, na przykład analitycznej, która nie ma jeszcze biblioteki dla React Native. Drugi przypadek to rzadziej używana funkcja systemu, dla której nikt nie utrzymuje biblioteki.

Źródło: [Expo Documentation, Expo Modules API, Overview](https://docs.expo.dev/modules/overview/), dostęp 2026-10-09

W naszych aplikacjach moduł natywny dochodzi wtedy, gdy funkcja tego wymaga. W AlertMe obok React Native, Expo i TypeScriptu są wśród technologii Kotlin i Swift.

Projekt: [AlertMe](https://kontaktio.pl/aplikacje-mobilne/alertme)

AlertMe ma jeden kod dla iPhone'a i Androida, z dwoma trybami, dla osoby chronionej i dla patrolu, oraz z interfejsem po polsku, angielsku, ukraińsku i hiszpańsku. Aplikacja jest w App Store i Google Play, a dyżurny w centrali agencji pracuje na osobnym pulpicie. Cały zakres opisuje strona projektu [AlertMe](https://kontaktio.pl/aplikacje-mobilne/alertme).

## Testy w TestFlight i Google Play

Przed wydaniem aplikację instalują na swoich telefonach testerzy, na iPhonie przez TestFlight, a na Androidzie z jednej ze ścieżek testów Google Play. Testy na fizycznych urządzeniach są w zakresie naszej usługi aplikacji mobilnych, a działającą wersję aplikacji pokazujemy jeszcze w trakcie prac.

TestFlight to usługa Apple do udostępniania testowych wersji aplikacji. Testerami wewnętrznymi może być do 100 użytkowników App Store Connect z dostępem do aplikacji, a testerów zewnętrznych, zapraszanych e-mailem albo publicznym linkiem, może być do 10 000. Testerzy korzystają z bezpłatnej aplikacji TestFlight, a każdą kompilację, czyli przesłany plik wersji, można testować do 90 dni.

Testy zewnętrzne zaczynają się po zatwierdzeniu kompilacji przez Apple. Przegląd jest wymagany przy pierwszej kompilacji dodanej do grupy testerów, a kolejne mogą nie wymagać pełnego przeglądu.

Źródło: [App Store Connect Help, TestFlight overview](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/), dostęp 2026-10-09

Google Play ma trzy ścieżki testów przed wydaniem produkcyjnym. Test wewnętrzny obejmuje do 100 osób, a nowa wersja jest u nich w ciągu kilku minut. Testerów testu zamkniętego można dodać z list adresów e-mail, do 200 list po 2000 osób. Test otwarty jest widoczny w Google Play i może do niego dołączyć każdy. Opinie testerów nie wpływają na publiczną ocenę aplikacji.

Źródło: [Play Console Help, Set up an open, closed, or internal test](https://support.google.com/googleplay/android-developer/answer/9845334?hl=en), dostęp 2026-10-09

Przy nowych kontach osobistych, założonych po 13 listopada 2023 roku, Google wymaga przed publikacją testu zamkniętego. Musi w nim uczestniczyć co najmniej 12 testerów, zapisanych nieprzerwanie przez co najmniej 14 dni. Aplikacje naszych klientów wychodzą z kont deweloperskich ich firm.

Źródło: [Play Console Help, App testing requirements for new personal developer accounts](https://support.google.com/googleplay/android-developer/answer/14151465?hl=en), dostęp 2026-10-09

## Przegląd przy każdej nowej wersji

Każdą aktualizację aplikacji w App Store, także z samymi poprawkami, Apple sprawdza przed publikacją. W Google Play zmiany, które wymagają przeglądu, trafiają do użytkowników dopiero po zatwierdzeniu przez Google. Wersje z jednego kodu wydaje się w obu sklepach, więc aktualizacja czeka zwykle na decyzje Apple i Google. Typowe czasy przeglądu w obu sklepach zebraliśmy w poradniku o [publikacji aplikacji w App Store i Google Play](https://kontaktio.pl/wiedza/publikacja-aplikacji-w-sklepach).

Według Apple średnio ponad 40% nierozwiązanych problemów w przeglądzie dotyczy wytycznej 2.1 o kompletności aplikacji. Obejmuje ona między innymi awarie, treści zastępcze i niepełne informacje.

Źródło: [Apple Developer, App Review](https://developer.apple.com/distribute/app-review/), dostęp 2026-10-09

Źródło: [Play Console Help, Control when app changes are reviewed and published](https://support.google.com/googleplay/android-developer/answer/9859654?hl=en), dostęp 2026-10-09

Część poprawek Expo pozwala dostarczyć bez nowej wersji w sklepie, jako aktualizację OTA, czyli przez internet. Usługa EAS Update, działająca z biblioteką expo-updates, aktualizuje w ten sposób nienatywne części aplikacji, takie jak kod JavaScript, style i obrazy, a użytkownik dostaje zmianę przy kolejnym uruchomieniu. Zmiana kodu natywnego, uprawnień, na przykład do aparatu albo lokalizacji, czy wersji Expo SDK wymaga nowej wersji w sklepach. Dokumentacja Expo dodaje, że zmiany w działaniu aplikacji zwykle wymagają przeglądu.

Źródło: [Expo Documentation, EAS Update](https://docs.expo.dev/eas-update/introduction/), dostęp 2026-10-09

Zasady sklepów zawężają tę drogę. Wytyczne Apple w punkcie 2.5.2 zabraniają aplikacji pobierania kodu, który dodaje albo zmienia jej funkcje. Umowa licencyjna programu Apple dla deweloperów dopuszcza pobieranie kodu interpretowanego pod kilkoma warunkami, między innymi takim, że nie zmienia on głównego przeznaczenia aplikacji. Google Play zakazuje pobierania spoza sklepu kodu wykonywalnego, ale nie dotyczy to kodu uruchamianego przez interpreter z pośrednim dostępem do interfejsów Androida, na przykład JavaScriptu. Taki kod nie może jednak umożliwiać naruszeń zasad Google Play.

Źródło: [Apple Developer, App Review Guidelines, punkt 2.5.2](https://developer.apple.com/app-store/review/guidelines/), dostęp 2026-10-09

Źródło: [Apple Developer Program License Agreement, punkt 3.3.1 B](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/), dostęp 2026-10-09

Źródło: [Play Console Help, Device and Network Abuse](https://support.google.com/googleplay/android-developer/answer/16559646?hl=en), dostęp 2026-10-09

## Aktualizacje pod nowe wersje systemów

Aplikację w sklepach trzeba co pewien czas dostosować do wymagań Apple i Google, które rosną razem z kolejnymi wersjami iOS i Androida. Pod wspólnym kodem są dwa projekty natywne, na Androida i na iOS. Według dokumentacji Expo w aplikacji na kilka platform każdy taki projekt trzeba utrzymywać na bieżąco z najnowszymi wersjami systemów.

Źródło: [Expo Documentation, Continuous Native Generation (CNG)](https://docs.expo.dev/workflow/continuous-native-generation/), dostęp 2026-10-09

W Google Play liczy się docelowy poziom API, czyli wersja Androida, pod którą przygotowano aplikację. Od 31 sierpnia 2026 roku Google przyjmuje nowe aplikacje i aktualizacje na telefony tylko wtedy, gdy celują co najmniej w Androida 16, czyli poziom API 36. Aplikacja już obecna w sklepie, która celuje w Androida 14 lub starszego, jest dla nowych użytkowników dostępna tylko na telefonach z tą samą albo starszą wersją systemu. Google pozwala wnioskować o przedłużenie terminu do 1 listopada 2026 roku.

Źródło: [Play Console Help, Target API level requirements for Google Play apps](https://support.google.com/googleplay/android-developer/answer/11926878?hl=en), dostęp 2026-10-09

Apple od 28 kwietnia 2026 roku przyjmuje w App Store Connect tylko kompilacje z Xcode 26 lub nowszego, z pakietem SDK dla iOS 26. Xcode to zestaw narzędzi Apple do budowy, testowania i wydawania aplikacji.

Źródło: [Apple Developer, Upcoming Requirements](https://developer.apple.com/news/upcoming-requirements/), dostęp 2026-10-09

Źródło: [Apple Developer, Xcode](https://developer.apple.com/xcode/), dostęp 2026-10-09

Każda wersja Expo SDK ma w dokumentacji przypisane najstarsze obsługiwane wersje Androida i iOS oraz wersję Xcode. Expo SDK 57 ustawia docelowy poziom API 36 i obsługuje telefony z Androidem od wersji 7 oraz z iOS od wersji 16.4. Nowe wersje SDK wychodzą trzy razy w roku, a przy przejściu na nowszą dokumentacja Expo radzi uwzględnić wymagania obu sklepów.

Źródło: [Expo Documentation, Expo SDK reference](https://docs.expo.dev/versions/latest/), dostęp 2026-10-09

Te prace obejmuje u nas opieka po uruchomieniu, w której są też serwer i kopie zapasowe. Za opiekę płacisz stałą kwotę co miesiąc, a jej wysokość ustalamy osobno dla każdej aplikacji. Rozbudowa o nowe funkcje to osobna wycena, a błędy w zbudowanej przez nas aplikacji naprawiamy bez dopłat.

## Kiedy wystarcza aplikacja webowa

Aplikacja webowa (PWA) wystarcza, gdy korzystają z niej pracownicy albo właściciel firmy, a sama aplikacja obywa się bez lokalizacji w tle oraz, na iPhonie, bez Bluetooth i NFC. Instaluje się ją z przeglądarki, bez publikacji w sklepach z aplikacjami, a nowa wersja nie czeka na przegląd w sklepie. W naszym cenniku aplikacja webowa ma cenę wyjściową od 10 000 zł.

Wersję w App Store i Google Play doradzamy, gdy aplikacja ma przekazywać pozycję przy wygaszonym ekranie albo obsługiwać alarmy, na które trzeba reagować od razu, jak AlertMe. Tak samo jest wtedy, gdy Twoi klienci mają ją sami znaleźć w wyszukiwarce sklepu. Tabelę możliwości PWA na obu systemach zawiera [strona o aplikacjach PWA dla firm](https://kontaktio.pl/aplikacje-mobilne/aplikacja-pwa), a oba warianty porównuje poradnik [PWA czy aplikacja natywna](https://kontaktio.pl/wiedza/aplikacja-pwa-czy-sklep).

## Ile kosztuje aplikacja na iOS i Androida

Za aplikację na iOS i Androida, wydawaną w obu sklepach, nasz cennik podaje cenę wyjściową od 20 000 zł. Kwotę dla Twojej aplikacji ustalamy w rozmowie o jej zakresie, a po wycenie pozostaje ona stała.

Cenę podnoszą funkcje, które w kalkulatorze leżą poza ceną wyjściową aplikacji, czyli logowanie użytkowników, powiadomienia, płatności w aplikacji, panel administracyjny oraz połączenie z programami firmy. Budowa trwa od kilku tygodni do kilku miesięcy, a pierwszą działającą wersję pokazujemy w trakcie prac. Harmonogram z datami odbiorów przygotowujemy po ustaleniu zakresu, przed startem.

W kalkulatorze odpowiedź „W App Store i Google Play” na pytanie, gdzie ma działać aplikacja, wybiera próg aplikacji w sklepach. Termin nie zmienia wyniku, a wynik razem z czasem realizacji możesz wysłać opiekunowi klienta.

Kalkulator kosztu: https://kontaktio.pl/wycena

Czynniki ceny aplikacji opisuje szerzej poradnik [ile kosztuje aplikacja mobilna](https://kontaktio.pl/wiedza/ile-kosztuje-aplikacja-mobilna), a tabelę cen wyjściowych ma strona [kalkulatora kosztu](https://kontaktio.pl/wycena). Na wycenę wystarczą informacje, do czego ma służyć aplikacja, kto będzie jej używał i z jakimi programami Twojej firmy ma się łączyć, bez specyfikacji technicznej. Na opis wysłany formularzem pod artykułem odpowiada opiekun klienta, z reguły w tym samym dniu roboczym.

---

Kontaktio. Agencja interaktywna i software house z Łodzi (kontaktio.pl): aplikacje mobilne, strony i sklepy internetowe oraz systemy dla firm. Kontakt: kontakt@kontaktio.pl, telefon 663 361 219, formularz https://kontaktio.pl/#kontakt. Treść całego serwisu w jednym pliku: https://kontaktio.pl/llms-full.txt