Jak stworzyć aplikację mobilną dla firmy — od wyboru platformy do publikacji w sklepie

Aplikacja mobilna ma w harmonogramie dwóch uczestników, których nie ma w umowie: Apple i Google. Wykonawca może zbudować aplikację w terminie, a mimo to nie opublikować jej na czas — bo firma nie ma jeszcze numeru potrzebnego do założenia konta, bo nowe konto w Google Play wymaga dwutygodniowego testu, albo bo przegląd w sklepie odesłał wersję do poprawki. Żadnej z tych rzeczy nie widać w wycenie, a każda przesuwa datę startu.

Ten tekst jest o tej drugiej połowie pracy. Pokazuje, od której platformy zacząć, czym różnią się aplikacje natywne i wieloplatformowe, co zmienia projektowanie na telefon i jak wygląda droga aplikacji do sklepu — krok po kroku, z terminami, które podają sami Apple i Google. Sam przebieg projektu, od briefu przez prototyp po odbiór, opisujemy w tekście o tym, jak stworzyć aplikację dla firmy; tu skupiamy się na tym, co jest inne w aplikacji na telefon.

Czy to ma być aplikacja ze sklepu

Zanim zaczniecie planować aplikację mobilną, warto rozstrzygnąć, czy musi ona trafić do App Store i Google Play. Część potrzeb, z którymi firmy przychodzą po „aplikację na telefon”, lepiej obsługuje dobrze zrobiona strona albo aplikacja webowa, a część — PWA, czyli strona, którą można zainstalować na telefonie bez sklepu.

Kryteria tej decyzji — jak często użytkownicy do Was wracają, czy potrzebujecie funkcji telefonu i czy sklep jest dla Was kanałem dotarcia — opisujemy w tekście co to jest aplikacja mobilna i kiedy ma sens w firmie, a granice PWA na iPhonie i Androidzie w tekście PWA — co to jest i kiedy zastąpi aplikację ze sklepu. Dalej zakładamy, że decyzja zapadła: aplikacja ma być w sklepie.

Android czy iOS — od czego zacząć

Pierwsza decyzja projektowa brzmi zwykle: na którą platformę najpierw. Rynek podpowiada Androida. W Polsce w sierpniu 2026 roku Android miał 69,3% odsłon z telefonów, a iOS 30,6% (StatCounter). Przy takiej przewadze start od Androida wydaje się oczywisty.

To, kto będzie korzystał z Waszej aplikacji, może jednak wyglądać inaczej niż średnia krajowa. Wśród gości naszej strony, którzy przychodzą z telefonu — a piszemy głównie dla firm — iOS ma 39,5%, a Android 60,3%. To dane z Google Analytics z ostatniego roku, obejmujące wyłącznie osoby, które zgodziły się na analitykę, więc traktujcie je jako wskazówkę, nie pomiar całego rynku. Kierunek jest jednak wyraźny: w ruchu firmowym iPhone'ów jest więcej, niż wynikałoby ze statystyk ogólnych.

Wniosek dla aplikacji firmowej jest taki, że start od jednej platformy odcina znaczną część odbiorców — i nie zawsze tę, którą zakładacie. Jeśli aplikacja jest dla Waszych klientów, sprawdźcie w swojej analityce, z jakich telefonów przychodzą. Jeśli jest dla pracowników, sprawdźcie, jakie telefony firma im wydaje. Dopiero te dwie liczby mówią, czy budować na obie platformy od razu, czy zacząć od jednej — i od której.

Natywna czy wieloplatformowa — React Native i Flutter, co to jest

Druga decyzja dotyczy tego, jak aplikacja jest zbudowana. Są tu dwie główne drogi.

Aplikacja natywna jest pisana osobno dla każdego systemu, w narzędziach i językach przygotowanych przez Apple i Google. Najpełniej korzysta z możliwości telefonu, ale oznacza dwie bazy kodu, dwa zestawy testów i zwykle dwa zespoły albo zespół, który zna oba światy.

Aplikacja wieloplatformowa powstaje z jednego kodu, który trafia na oba systemy. Najczęściej używa się do tego dwóch technologii. React Native, rozwijany przez Meta, pozwala pisać aplikację w JavaScripcie i — jak mówi jego dokumentacja — w czasie działania tworzy odpowiadające jej widoki Androida i iOS (React Native). Flutter, rozwijany przez Google, używa języka Dart i rysuje interfejs własnym silnikiem. W obu przypadkach użytkownik dostaje aplikację, która wygląda i działa jak natywna, a firma — jedną bazę kodu.

Warto uważać na słowo „hybrydowa”. Oznacza ono zwykle stronę internetową zamkniętą w natywnym okienku, a nie aplikację w React Native czy Flutterze — i w ofertach bywa używane dla obu, co utrudnia porównanie. Jeśli wykonawca proponuje „aplikację hybrydową”, zapytajcie, w jakiej technologii dokładnie.

Aplikacja wieloplatformowa nie zmienia jednej rzeczy: pisze się ją raz, ale publikuje dwa razy. Są dwa sklepy, dwa konta, dwa przeglądy i dwa zestawy wymagań, które zmieniają się co roku. Oszczędność na kodzie jest realna; oszczędności na drodze do sklepu nie ma.

Projektowanie aplikacji mobilnych

Projekt aplikacji na telefon to nie projekt strony w mniejszej skali. Trzy różnice zmieniają decyzje, które na komputerze nie mają znaczenia.

Kciuk zamiast myszy. Aplikację obsługuje się często jedną ręką, w ruchu, w rękawiczkach albo z torbą w drugiej ręce. Najważniejsze akcje muszą być w zasięgu kciuka, a przyciski na tyle duże, żeby dało się w nie trafić bez celowania. To, co na komputerze jest drobną niewygodą, na telefonie jest powodem, żeby zrezygnować.

Przerwany zasięg. Telefon traci połączenie w windzie, w piwnicy magazynu i na trasie. Aplikacja musi wiedzieć, co zrobić, kiedy sieci nie ma: pokazać zapisane dane, przyjąć wpis i wysłać go później, albo uczciwie powiedzieć, że dana funkcja wymaga połączenia. To decyzja, którą podejmuje się na etapie projektu, a nie po skargach użytkowników.

Powiadomienia jako część produktu. Na telefonie powiadomienie często jest głównym powodem, dla którego ktoś otwiera aplikację. Trzeba zaprojektować, kiedy je wysyłać, o czym i jak często — i co się stanie, jeśli użytkownik się na nie nie zgodzi. Aplikacja, która bez powiadomień traci sens, powinna o nie poprosić w momencie, w którym ich wartość jest oczywista, a nie przy pierwszym uruchomieniu.

Wytyczne Apple i Google — dwie konwencje, jedna aplikacja

Każda z platform ma własny zbiór zasad projektowania: Apple publikuje Human Interface Guidelines, Google — Material Design. Opisują, jak wyglądają i jak zachowują się podstawowe elementy: nawigacja, przyciski, listy, okna dialogowe, powrót do poprzedniego ekranu. Użytkownicy znają te konwencje ze wszystkich innych aplikacji na swoim telefonie, nawet jeśli nigdy o nich nie czytali — i każde odstępstwo odbierają jako „coś tu nie działa”.

Dla aplikacji wieloplatformowej to wyzwanie, bo jeden kod ma zachowywać się naturalnie w dwóch różnych konwencjach. Dobre zespoły rozwiązują to tak, że wspólna jest logika i wygląd marki, a elementy systemowe — nawigacja, gesty, okna — zachowują się tak, jak na danej platformie. Zapytajcie wykonawcę, jak to robi. Jeśli odpowiedź brzmi „aplikacja wygląda wszędzie tak samo”, to na jednym z systemów będzie wyglądała obco.

Poza tym projekt aplikacji mobilnej przebiega tak samo jak każdej innej: od makiety, przez klikalny prototyp, do projektu graficznego. Tę część, z rolą zamawiającego na każdym etapie, opisujemy w tekście o procesie tworzenia aplikacji.

Aplikacja mobilna potrzebuje zaplecza

Aplikacja na telefonie rzadko działa sama. Zamówienia, zgłoszenia, dane klientów czy stany magazynu muszą gdzieś być przechowywane i skądś przychodzić — z serwera, z którym aplikacja się komunikuje przez interfejs programistyczny, czyli API. Jeśli macie już aplikację webową albo panel dla klientów, aplikacja mobilna może korzystać z tego samego zaplecza. Jeśli nie, trzeba je zbudować, i to jest osobna pozycja w harmonogramie: w regułach, według których planujemy projekty, przygotowanie API dla aplikacji mobilnej to od trzech do sześciu tygodni.

Druga rzecz to systemy, których już używacie. Aplikacja dla handlowców, która nie widzi stanów z systemu magazynowego, albo aplikacja serwisowa, która nie zapisuje zleceń w CRM, szybko staje się kolejnym miejscem, do którego trzeba coś przepisywać ręcznie. Każda taka integracja to osobna praca i osobne ryzyko — warto wypisać je w briefie, zanim wykonawca poda termin.

Konto deweloperskie: Google Play i Apple Developer Program

Żeby aplikacja trafiła do sklepu, ktoś musi ją tam opublikować z własnego konta deweloperskiego — w Apple Developer Program dla App Store i w Konsoli Google Play dla sklepu Google. I tu pojawia się decyzja, która wydaje się formalnością, a ma długie skutki: na kogo jest to konto.

Konto powinno należeć do Waszej firmy, nie do wykonawcy. Kto ma konto, ten jest wydawcą aplikacji: to jego nazwa widnieje w sklepie, on przyjmuje płatności i on decyduje o każdej wersji. Jeśli aplikacja zostanie opublikowana z konta wykonawcy, zmiana wykonawcy w przyszłości oznacza przenoszenie aplikacji między kontami, które nie zawsze jest proste — a w najgorszym razie publikację od nowa, z utratą ocen i pobrań.

Oba sklepy rozróżniają konta osób prywatnych i organizacji. Dla firmy właściwe jest konto organizacji, a oba sklepy wymagają przy nim tego samego dokumentu: numeru D-U-N-S (Apple, Google Play). Opłaty za konta i koszty, które wracają co roku, zestawiamy w tekście o aplikacjach mobilnych w firmie.

Numer DUNS — co to jest i skąd go wziąć

Numer D-U-N-S to dziewięciocyfrowy identyfikator firmy nadawany przez Dun & Bradstreet. Apple i Google używają go, żeby sprawdzić, że firma, która zakłada konto, istnieje i jest tym, za kogo się podaje. Bez niego konta organizacji w żadnym z dwóch sklepów nie założycie.

Dobra wiadomość jest taka, że numer jest bezpłatny, a wiele firm ma go już nadanego, nawet o tym nie wiedząc. Apple udostępnia wyszukiwarkę, w której można to sprawdzić, i formularz, przez który można złożyć wniosek o nowy numer. Zła wiadomość dotyczy czasu: Apple zaleca, żeby na otrzymanie numeru od Dun & Bradstreet przeznaczyć do pięciu dni roboczych, a potem do dwóch kolejnych, zanim Apple otrzyma dane i pozwoli założyć konto firmowe (Apple, D-U-N-S Number).

W praktyce oznacza to, że numer D-U-N-S warto sprawdzić albo zamówić na samym początku projektu — w tym samym tygodniu, w którym podpisujecie umowę z wykonawcą. Zrobiony na końcu, przesuwa start o półtora tygodnia z powodu, który nie ma nic wspólnego z aplikacją.

Test zamknięty i przegląd — droga do sklepu

Kiedy aplikacja jest gotowa, zaczyna się etap, na który wykonawca ma najmniejszy wpływ. Poniższa figura zbiera wszystkie kroki razem z terminami, które podają same sklepy.

Test zamknięty w Google Play. Google wymaga, żeby deweloperzy z kontami prywatnymi założonymi po 13 listopada 2023 roku przed publikacją przeprowadzili test zamknięty z co najmniej 12 testerami, którzy są w nim bez przerwy przez co najmniej 14 dni (Google Play). Do grudnia 2024 roku wymóg dotyczył 20 testerów, dlatego w wielu poradnikach wciąż krąży ta liczba. Strona Google opisuje ten obowiązek dla kont prywatnych; o kontach organizacji nie mówi. To kolejny powód, żeby aplikację firmy publikować z konta firmy — ale jeśli z jakiegoś powodu zaczynacie od konta prywatnego, te dwa tygodnie trzeba wpisać w harmonogram.

Przegląd w sklepie. Każda aplikacja, zanim trafi do użytkowników, przechodzi przegląd. Apple podaje, że średnio 90% zgłoszeń sprawdza w mniej niż 24 godziny (Apple, App Review). Google zastrzega, że dla niektórych kont i aplikacji przegląd może potrwać do siedmiu dni, a w wyjątkowych przypadkach dłużej (Google Play). Szybki przegląd nie znaczy jednak, że zawsze pozytywny: odrzucenie z prośbą o poprawkę to normalna część pierwszej publikacji, i warto zostawić na nią zapas.

Każda kolejna wersja. Przegląd nie kończy się na pierwszej publikacji. Każda aktualizacja — także poprawka błędu — wraca do kolejki. W aplikacji webowej poprawkę wgrywa się w kilka minut; w aplikacji ze sklepu trzeba doliczyć czas przeglądu, i to w obu sklepach osobno.

Testy aplikacji mobilnej na prawdziwych urządzeniach

Aplikacja, która działa na telefonie programisty, nie musi działać na telefonie Waszego klienta. Na iPhonie problem jest mniejszy, bo modeli jest niewiele, a większość użytkowników szybko instaluje nowe wersje systemu. Na Androidzie jest odwrotnie: telefony produkuje wielu producentów, każdy z własnymi zmianami w systemie, o różnych ekranach i różnej mocy, a stare wersje systemu żyją latami. Błąd, który pojawia się tylko na jednym modelu popularnej marki, potrafi dotknąć dużej części użytkowników.

Dlatego testy aplikacji mobilnej prowadzi się na prawdziwych urządzeniach, nie tylko w emulatorze. W naszym procesie to macierz od trzech do pięciu modeli iPhone'a na dwóch najnowszych wersjach iOS i od czterech do sześciu modeli Androida kilku marek na trzech najnowszych wersjach systemu, sprawdzana w różnych warunkach sieci — od dobrego Wi-Fi po brak zasięgu. Jeśli aplikacja jest dla Waszych pracowników, najprostsza zasada brzmi: testujcie na telefonach, które im wydajecie.

Zapytajcie wykonawcę, na jakich urządzeniach będzie testował, i poproście o tę listę na piśmie. Odpowiedź „na emulatorach i swoich telefonach” oznacza, że część błędów znajdą dopiero Wasi użytkownicy — a w aplikacji ze sklepu każda poprawka przechodzi jeszcze przegląd.

Ile trwa zrobienie aplikacji mobilnej

Czas aplikacji mobilnej to suma dwóch zegarów: budowy i sklepów. W naszym procesie budowa składa się z etapów, których długość zależy od zakresu: Discovery trwa od jednego do trzech tygodni, projekt graficzny i UX od dwóch do czterech, programowanie od sześciu do dwudziestu czterech, testy na prawdziwych urządzeniach od dwóch do czterech, a publikacja w sklepach od jednego do trzech tygodni. Jeśli aplikacja potrzebuje własnego zaplecza, z którym ma się komunikować, w regułach, według których planujemy projekty, dochodzi do tego od trzech do sześciu tygodni na przygotowanie API.

Zegar sklepów biegnie częściowo równolegle, ale tylko wtedy, gdy się o niego zadba. Numer D-U-N-S i konta firmowe można założyć w pierwszym tygodniu projektu, kiedy trwa Discovery. Zostawione na koniec, dokładają półtora tygodnia do terminu, którego nikt nie przewidział. Tak samo z testami: jeśli testerzy z Waszej firmy korzystają z wersji testowych od połowy programowania, na końcu nie trzeba na nich czekać.

Po publikacji

Aplikacja w sklepie nie jest skończona. Apple i Google co roku wydają nowe wersje systemów, a sklepy aktualizują wymagania wobec aplikacji — dotyczące prywatności, uprawnień czy minimalnych wersji narzędzi, którymi aplikacja jest budowana. Aplikacja, której nikt nie aktualizuje, po pewnym czasie przestaje spełniać wymagania i może zostać ukryta albo nie przejść przeglądu przy najbliższej poprawce.

Dlatego utrzymanie aplikacji mobilnej to koszt stały, a nie jednorazowy: aktualizacje pod nowe systemy, poprawki po zmianach w sklepach, odnawianie konta Apple. Z czego składa się ten rachunek, rozpisujemy w tekście ile kosztuje stworzenie aplikacji, a ceny rynkowe samego wykonania — w raporcie kosztów aplikacji mobilnych.

Kiedy szukacie wykonawcy

Jeśli po tej lekturze wiecie, że aplikacja ze sklepu jest Wam potrzebna, i szukacie firmy, która ją zbuduje i przeprowadzi przez publikację, opisujemy, jak tworzymy aplikacje mobilne dla firm — od Discovery, przez testy na prawdziwych urządzeniach, po publikację z konta należącego do Was.