Aplikacja na iOS i Androida z jednego kodu w React Native.
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.
Kontaktio · opublikowano
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łoReact Native, Platform-Specific Code (reactnative.dev, dostęp )
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łoReact Native, Get Started with React Native (reactnative.dev, dostęp )
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łoReact Native, strona projektu (reactnative.dev, dostęp )
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łoReact Native, Core Components and Native Components (reactnative.dev, dostęp )
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.
ŹródłoExpo Documentation, Core concepts (docs.expo.dev, dostęp )
ŹródłoReact Native, Get Started with React Native (reactnative.dev, dostęp )
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łoExpo Documentation, EAS Build (docs.expo.dev, dostęp )
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łoExpo Documentation, Submit to app stores (docs.expo.dev, dostęp )
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łoReact Native, Native Modules, Introduction (reactnative.dev, dostęp )
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łoExpo Documentation, Expo Modules API, Overview (docs.expo.dev, dostęp )
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.
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.
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łoApp Store Connect Help, TestFlight overview (developer.apple.com, dostęp )
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łoPlay Console Help, Set up an open, closed, or internal test (support.google.com, dostęp )
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łoPlay Console Help, App testing requirements for new personal developer accounts (support.google.com, dostęp )
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.
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łoApple Developer, App Review (developer.apple.com, dostęp )
ŹródłoPlay Console Help, Control when app changes are reviewed and published (support.google.com, dostęp )
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łoExpo Documentation, EAS Update (docs.expo.dev, dostęp )
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łoApple Developer, App Review Guidelines, punkt 2.5.2 (developer.apple.com, dostęp )
ŹródłoApple Developer Program License Agreement, punkt 3.3.1 B (developer.apple.com, dostęp )
ŹródłoPlay Console Help, Device and Network Abuse (support.google.com, dostęp )
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łoExpo Documentation, Continuous Native Generation (CNG) (docs.expo.dev, dostęp )
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łoPlay Console Help, Target API level requirements for Google Play apps (support.google.com, dostęp )
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łoApple Developer, Upcoming Requirements (developer.apple.com, dostęp )
ŹródłoApple Developer, Xcode (developer.apple.com, dostęp )
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łoExpo Documentation, Expo SDK reference (docs.expo.dev, dostęp )
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, a oba warianty porównuje poradnik PWA czy aplikacja natywna.
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.
Czynniki ceny aplikacji opisuje szerzej poradnik ile kosztuje aplikacja mobilna, a tabelę cen wyjściowych ma strona kalkulatora kosztu. 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.