Wdrożenie aplikacji mobilnej

Bezpłatna konsultacja Projekty

Budujemy aplikację na iOS i Androida, doprowadzamy ją do wydania w App Store i Google Play, a konta deweloperskie, certyfikaty i klucz podpisujący zapisujemy na Twoją firmę. Po ostatnim wydaniu Twój zespół wypuszcza kolejne wersje bez nas.

Pracowaliśmy dla najlepszych firm i startupów

Wyzwania

Trzy momenty, w których aplikacja przestaje być pomysłem, a staje się decyzją

Nie masz pewności, czy potrzebujesz aplikacji, czy wystarczy dobra strona mobilna? Umów konsultację - czasem uczciwa odpowiedź brzmi „nie budujcie aplikacji", i wtedy tak właśnie powiemy.

  • „Klienci pytają o aplikację, a Wy macie tylko stronę”

    Część funkcji wymaga aparatu, lokalizacji w tle albo powiadomienia w konkretnym momencie, a przeglądarka tego nie unosi. Do tego dochodzi miejsce w sklepie - tam klient szuka marki wtedy, gdy nie pamięta adresu strony.

  • „Aplikacja jest, ale wydanie zależy od jednej osoby”

    Klucz podpisujący leży na laptopie kogoś, kto zmienił pracę, konto w sklepie stoi na poprzednim wykonawcy, a ostatnia aktualizacja wyszła kilkanaście miesięcy temu. Odzyskanie kontroli nad wydaniem robimy wtedy przed dopisaniem pierwszej nowej funkcji.

  • „Projekt jest gotowy, brakuje kogoś, kto go wypuści”

    Ekrany wiszą w Figmie od miesięcy, bo zespół produktowy nie ma mocy, a rekrutacja developera mobilnego trwa dłużej niż samo wdrożenie. Wchodzimy w gotowy projekt, dopytujemy o stany, których w nim nie ma, i doprowadzamy rzecz do sklepu.

Dla kogo

Dla kogo prowadzimy to wdrożenie

  • Firmy z panelem webowym i pracą w terenie

    System działa w przeglądarce, ale korzystają z niego serwisanci, kierowcy albo handlowcy, którzy mają w ręku telefon i bywają poza zasięgiem. Aplikacja bierze na siebie tę część pracy, w której liczy się aparat, lokalizacja i możliwość zapisania czegoś bez sieci, a reszta zostaje w panelu.

  • Zespoły, które odziedziczyły aplikację po innym wykonawcy

    Kod jest, aplikacja stoi w sklepach, tylko nikt w firmie nie wie, gdzie leży klucz podpisujący i na kogo zarejestrowane jest konto. Zaczynamy od odzyskania kontroli nad wydaniem i przeniesienia aplikacji na Wasze konta, bo bez tego każda kolejna poprawka zależy od cudzej dobrej woli.

  • Startupy przed pierwszym wydaniem

    Funkcji na liście jest kilkadziesiąt, a pieniędzy starczy na jedno wydanie, więc największą wartość ma ktoś, kto pomoże tę listę przyciąć. Wybieramy zakres, który da się wypuścić i utrzymać, a resztę wpisujemy w kolejne wersje zamiast w pierwszą.

  • Firmy z aplikacją dla własnych pracowników

    Aplikacja nie musi trafić do publicznego sklepu, bo używa jej kilkuset pracowników albo wybrani partnerzy. Dystrybucję prowadzimy wtedy kanałami przeznaczonymi do tego przez Apple i Google, a zasady prywatności i uprawnień traktujemy tak samo poważnie jak przy wydaniu publicznym.

Wydruki czterech układów interfejsu na stole: pulpit, ekran telefonu, formularz i tabela, jeden blok zakreślony markerem

Nasza różnica

Czym różni się nasze wdrożenie

  • Konta i klucze stoją na Was od pierwszego tygodnia

    Konto deweloperskie w Apple i Google zakładamy na Waszą firmę, a klucz podpisujący i certyfikaty lądują w Waszym menedżerze haseł, zanim powstanie pierwsza paczka. Zakończenie współpracy jest wtedy odebraniem nam dostępu, a nie migracją aplikacji między kontami, na którą trzeba osobnego projektu.

  • Zgłoszenie przygotowane pod zasady recenzji, nie pod nadzieję

    Najczęstsze powody odrzuceń są znane i opisane publicznie - brak ścieżki usunięcia konta, uprawnienia bez uzasadnienia, rozjazd między formularzem prywatności a tym, co aplikacja naprawdę zbiera, logowanie zamknięte za ścianą bez konta testowego. Przechodzimy tę listę przed wysyłką, a korespondencję z recenzją prowadzimy sami.

  • Technologię wybieramy po zakresie, nie przed nim

    Wspólny kod na obie platformy skraca budowę i utrzymanie, ale przy intensywnej grafice, pracy w tle albo ścisłej integracji ze sprzętem natywny kod wygrywa. Decyzję podejmujemy po przejściu listy funkcji i mówimy wprost, kiedy Waszej sprawy nie rozwiąże aplikacja, tylko dobra strona mobilna.

  • Kończymy, gdy wydajecie wersję 1.1 bez nas

    Hand-off to nie archiwum plików, tylko wydanie zrobione Waszymi rękami na naszych oczach - na kanale testowym, z checklisty, z pipeline'u, który macie u siebie. Dopóki Wasz zespół nie wypuści paczki samodzielnie, uznajemy wdrożenie za niedokończone.

Proces

8–14 tygodni od ustalenia zakresu do zgłoszenia w obu sklepach

  1. Tydzień 1

    Zakres, platformy i wybór technologii

    Przechodzimy przez listę funkcji i odsiewamy te, które nie muszą wejść do pierwszego wydania. Ustalamy, czy zakres uzasadnia kod natywny, czy wspólny na obie platformy, i jakich uprawnień urządzenia aplikacja naprawdę potrzebuje - każde z nich trzeba potem uzasadnić w formularzu prywatności.

  2. Tydzień 1–2

    Fundament: repozytorium, konta, środowiska

    Zakładamy konta deweloperskie na Twoją firmę - konto organizacji u Apple wymaga numeru D-U-N-S, o który występuje się wcześniej, bo potrafi zająć kilka dni. Generujemy certyfikaty i klucz podpisujący, dzielimy środowiska na testowe i produkcyjne, uruchamiamy budowanie paczek z gałęzi.

  3. Tydzień 2–9

    Budowa ekranów i integracje

    Ekrany powstają partiami, a każda partia kończy się paczką do zainstalowania na Waszych telefonach - nie zrzutem w prezentacji. Równolegle idą integracje: logowanie, płatności w aplikacji, powiadomienia, praca bez zasięgu i synchronizacja po powrocie sieci.

  4. Tydzień 8–11

    Testy na urządzeniach i kanały testowe

    Aplikacja trafia do TestFlight i do testów wewnętrznych w Play Console, więc zespół klika ją na własnych telefonach, zanim zobaczy ją ktokolwiek z zewnątrz. Sprawdzamy różne rozmiary ekranów, starsze wersje systemu, zachowanie przy słabym zasięgu i po odmowie uprawnień.

  5. Tydzień 11–14

    Zgłoszenie do sklepów i przekazanie wydań

    Kompletujemy metadane, zrzuty, politykę prywatności, formularze App Privacy i Data safety oraz ścieżkę usunięcia konta, po czym prowadzimy zgłoszenie i korespondencję z recenzją aż do publikacji. Na koniec przekazujemy dostępy, checklistę wydania i sesję dla zespołu.

Zakres

Trzy rzeczy. Aplikacja, komplet wydawniczy i kontrola nad wydaniami

  • Kod aplikacji na iOS i Androida

    Repozytorium w Twojej organizacji od pierwszego commita, z ekranami, integracjami i obsługą stanów, o które projekt zwykle nie pyta - braku sieci, odmowy uprawnień, wygasłej sesji. Wybór między wspólnym kodem a natywnym zapada po zakresie, nie przed nim.

  • Komplet wydawniczy do obu sklepów

    Konta w App Store Connect i Google Play Console, ikony i zrzuty ekranu w wymaganych rozmiarach, opisy pod wyszukiwanie w sklepie, polityka prywatności, formularze App Privacy i Data safety, klasyfikacja wiekowa oraz ścieżka usunięcia konta.

  • Pipeline wydań i dostępy po Twojej stronie

    Automatyczne budowanie i wysyłka paczek, kanały testowe (TestFlight, testy wewnętrzne w Play), klucz podpisujący i certyfikaty w Waszym sejfie, checklista wydania, raportowanie awarii oraz sesja, po której zespół wypuszcza wersję sam.

Warsztat

Co stosujemy

Wybór narzędzi zależy od zakresu, ale ten zestaw wraca w każdym wdrożeniu - pilnują go zasady obu sklepów, nie nasze upodobania.

Blat warsztatowy z góry: dwa wydruki układu interfejsu, lupa powiększająca jeden blok, stalowa linijka i wzornik szarości od bieli do czerni, jedna linia podkreślona pomarańczowym markerem
  • React Native z Expo albo Flutter
  • Swift i Kotlin, gdy zakres tego wymaga
  • Apple Human Interface Guidelines
  • Material Design + zasady Google Play
  • Wydanie z jednego polecenia (Fastlane / EAS)
  • Raporty awarii od pierwszego dnia w sklepie

Następny krok

Porozmawiajmy o Waszym projekcie

Powiedzcie, co macie do zrobienia. Wracamy z zakresem i wyceną.

Bezpłatna konsultacja Projekty

Realizacje

Realizacje z produktów, które doprowadzamy do sklepu

Projekty z tych typów produktów, przy których wdrożenie kończy się wydaniem mobilnym najczęściej. Część aplikacji powstaje pod marką zleceniodawcy i te pokazujemy na konsultacji.

Projekty

Efekty

Co dostajecie, w jakim terminie i po czym to sprawdzicie

  • 2 sklepy

    App Store i Google Play prowadzimy jako jedno wydanie - te same funkcje i ten sam numer wersji, dwa komplety metadanych i zrzutów ekranu

  • 8–14 tyg.

    Od ustalenia zakresu do zgłoszenia obu paczek; górna granica to aplikacja z logowaniem, płatnościami i pracą bez zasięgu

  • 0

    Tyle kont deweloperskich i kluczy podpisujących zostaje po naszej stronie - komplet stoi na Waszej firmie od pierwszego tygodnia, nie od hand-offu

  • 1 polecenie

    Tyle dzieli Wasz zespół od kolejnego wydania po przekazaniu - pipeline buduje paczkę i wysyła ją do obu sklepów

Terminy pochodzą z harmonogramu opisanego wyżej na tej stronie. Czasu recenzji ani decyzji Apple i Google nie obiecujemy, bo nie są po naszej stronie - obiecujemy zgłoszenie przygotowane pod obowiązujące zasady i prowadzenie korespondencji aż do publikacji.

Opinie klientów

Co mówią nasi klienci

  • „Praca z zespołem Wzór była naprawdę świetnym doświadczeniem! Zawsze szybko odpowiadali na nasze pytania i elastycznie podchodzili do naszych uwag. Mają mnóstwo kreatywnych pomysłów, a jednocześnie są bardzo rzetelni i terminowi. Efekt końcowy w pełni spełnił nasze oczekiwania, zdecydowanie polecamy każdemu, kto szuka profesjonalistów z pasją.”
    Maja Wieloch-Silecka Dyrektor operacyjny, Bosfor Group
  • „Nasi Klienci oczekują od nas szybkiego, skutecznego działania w bardzo szerokim zakresie. Od stworzenia brandu, przez budowę strony internetowej wraz ze sklepem po przeprowadzenie skutecznej kampanii sprzedażowej. Temat niełatwy, ale do zrobienia jeśli ma się zgrany zespół i firmy, z którymi wyzwania bierze się z marszu. Dla nas jakość, odpowiedzialność i zaangażowanie są kluczowe, a współpraca z Agencją UX Wzór zapewnia nam to w 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Współpraca z Agencją UX Wzór rozpoczęła się od naszej strony internetowej. Bardzo spodobał się nam sposób ich pracy. Dlatego podjęliśmy decyzję o podzlecaniu projektów realizowanych dla naszych Klientów w formie White Label. Bardzo spodobał nam się ich flow pracy, przekazywanie projektów naszemu zespołowi, ich dokumentacja czy praca na design systemie. Teraz możemy podejmować większe ryzyko.”
    Mateusz Swół Chief Operating Officer, Sellace

Czas i zakres

Ile trwa wdrożenie i co wpływa na wycenę

8–14 tygodni

Osiem tygodni to aplikacja o wąskim zakresie, zbudowana na gotowym projekcie i wspólnym kodzie na obie platformy. Czternaście to wydanie z logowaniem, płatnościami w aplikacji, pracą bez zasięgu albo wymaganiami branżowymi, które trzeba udokumentować przed zgłoszeniem.

  • Liczba ekranów i stanów, w których każdy z nich występuje

  • Zakres integracji - logowanie, płatności, powiadomienia, Wasze systemy

  • To, czy aplikacja ma działać bez zasięgu i synchronizować dane po powrocie

  • Punkt wyjścia - gotowy projekt w Figmie albo projektowanie od zera

  • Wymagania sklepów wynikające z branży i rodzaju zbieranych danych

Pytania

Pytania, które padają najczęściej

Ile kosztuje wdrożenie aplikacji mobilnej?

Wyceniamy indywidualnie, bo ten sam brief bywa aplikacją na dwanaście ekranów albo na sto. O kwocie decyduje pięć rzeczy: liczba ekranów wraz ze stanami, w których każdy z nich występuje; zakres integracji (logowanie, płatności w aplikacji, powiadomienia, Wasze systemy); to, czy aplikacja ma działać bez zasięgu; punkt wyjścia, czyli gotowy projekt w Figmie albo projektowanie od zera; oraz wymagania sklepów wynikające z branży i rodzaju zbieranych danych. Propozycję z rozbiciem na etapy dostajesz w ciągu dwóch dni roboczych od rozmowy o zakresie.

Natywnie czy jeden kod na obie platformy?

Wspólny kod (React Native z Expo albo Flutter) skraca budowę i utrzymanie, bo jedna poprawka wchodzi w obu sklepach naraz - i tak wygląda większość wdrożeń, w których aplikacja obsługuje formularze, listy, logowanie i płatności. Kod natywny w Swifcie i Kotlinie wybieramy tam, gdzie liczy się intensywna grafika, ciężka praca w tle, ścisła integracja ze sprzętem albo funkcje systemowe pojawiające się najpierw natywnie. Decyzję podejmujemy po przejściu listy funkcji, nie przed nią.

Czy macie pewność, że aplikacja przejdzie recenzję w sklepach?

Nie i nikt uczciwy takiej pewności nie da - decyzja i czas recenzji należą do Apple i Google. Odpowiadamy za to, na co mamy wpływ: przechodzimy przed wysyłką listę najczęstszych powodów odrzuceń, czyli brak ścieżki usunięcia konta, uprawnienia bez uzasadnienia, rozjazd między deklaracją prywatności a tym, co aplikacja naprawdę zbiera, oraz logowanie zamknięte bez konta testowego dla recenzenta. Jeśli mimo tego przyjdzie odrzucenie, korespondencję i poprawki prowadzimy my, w ramach zakresu.

Na kogo zarejestrowane są konta w sklepach i kto trzyma klucz podpisujący?

Na Waszą firmę, od pierwszego tygodnia. Konto deweloperskie Apple i Google zakładamy na Wasze dane (przy koncie organizacji Apple potrzebny jest numer D-U-N-S, więc występujemy o niego na starcie), a certyfikaty i klucz podpisujący lądują w Waszym menedżerze haseł, zanim powstanie pierwsza paczka. Aplikacji podpisanej cudzym kluczem nie da się później zaktualizować bez tego klucza - dlatego nie zostawiamy go u siebie nawet na czas projektu.

Mamy tylko projekt w Figmie. Albo nie mamy nic - dacie radę?

Oba warianty są w porządku. Gotowy projekt bierzemy w takim stanie, w jakim jest, i dopytujemy o to, czego zwykle w nim nie ma - stany puste, błędy, brak sieci, odmowa uprawnień. Gdy projektu nie ma, robimy go w ramach tego samego wdrożenia. Jeśli aplikacja ma być kolejnym produktem obok istniejących, warto zacząć od design systemu, żeby ekrany mobilne i webowe nie rozjechały się po pierwszym kwartale.

Czy naprawdę potrzebujemy aplikacji?

Czasem nie i mówimy to wprost. Jeśli aplikacja miałaby robić to, co strona, bez aparatu, lokalizacji w tle, powiadomień ani pracy bez zasięgu, to publikacja w sklepach dokłada dwa procesy recenzji i obowiązek aktualizacji, a nie daje nowej wartości. W takiej sytuacji szybciej i taniej wychodzi wdrożenie strony, a do rozmowy o aplikacji wracamy, gdy pojawi się funkcja, której przeglądarka nie unosi.

Co dzieje się po premierze - kto wypuszcza kolejne wersje?

Po hand-offie robi to Wasz zespół, bo pipeline, kanały testowe, checklista wydania i klucze są u Was, a ostatnie wydanie przed zakończeniem prac przeprowadzamy Waszymi rękami. Zostaje monitoring awarii, więc widać, co się psuje u realnych użytkowników. Jeśli wolicie oddać utrzymanie na zewnątrz, prowadzimy je osobno, w ustalonym wymiarze miesięcznym - ale to wybór, a nie warunek działania aplikacji.

Powiązane usługi

Powiązane usługi

Umów bezpłatną konsultację z ekspertem, aby omówić Twój projekt i otrzymać odpowiedzi na nurtujące Cię pytania.

- Patryk Korycki, CEO

Zaplanuj spotkanie
Umów bezpłatną konsultację