Gotowy kod to część uruchomienia.
Publikacja aplikacji mobilnej obejmuje produkt, konfigurację oraz materiały potrzebne użytkownikowi i sklepowi. Opis musi odpowiadać rzeczywistym funkcjom, ekrany pokazywać działanie, a wymagane informacje odzwierciedlać sposób używania danych. Warto przygotowywać je podczas realizacji, nie dopiero w dniu planowanego startu.
Jeśli aplikacja korzysta z kont i wspólnego serwera, potrzebne jest również gotowe środowisko produkcyjne. Rezerwacje, wiadomości i dane użytkownika nie mogą zależeć od tymczasowego komputera wykonawcy. Ustalamy, kto zarządza konfiguracją i kto ma kontakt do obsługi technicznej.
Dzień uruchomienia nie jest wyłącznie chwilą wgrania pliku. Trzeba określić grupę startową, obsługę zgłoszeń oraz sposób sprawdzenia, że użytkownik może wykonać podstawowe zadanie. Aplikacja webowa ma inną drogę udostępnienia, opisaną w porównaniu wariantów.
Własność kont ustalamy wcześniej.
Przed zgłoszeniem określamy, na jakim koncie i w czyim imieniu będzie udostępniony produkt. Firma powinna wiedzieć, kto ma dostęp do wersji, materiałów oraz przyszłych aktualizacji. Konto wykonawcy i konto właściciela produktu nie są domyślnie tym samym rozwiązaniem.
Wymagania zależą od platformy, typu konta i sytuacji aplikacji. Proces może obejmować potwierdzenie danych oraz przygotowanie dostępu dla osób odpowiedzialnych za publikację. Nie wpisujemy do oferty uniwersalnego terminu bez sprawdzenia, jakie kroki dotyczą danego projektu.
Dostęp roboczy przyznajemy odpowiednim rolom, bez przesyłania haseł w publicznych materiałach. Przed przekazaniem ustalamy także, kto będzie odnawiać wymagane usługi i przygotowywać kolejne wydania. To element ciągłości produktu po pierwszej publikacji.
Opis i zrzuty przedstawiają rzeczywisty produkt.
Przygotowujemy nazwę, ikonę, opis i ekrany odpowiadające funkcjom dostępnej wersji. Materiały nie powinny obiecywać integracji lub usług, które pozostają na liście rozwoju. Jeśli część działań wymaga konta albo określonej lokalizacji, informacja powinna być zrozumiała.
Apple wymienia przygotowanie informacji o produkcie, danych i ocenie wiekowej w materiałach dotyczących zgłaszania aplikacji. Dokładne wymagania oraz formaty sprawdzamy dla aktualnego wydania i odpowiedniego typu produktu.
Informacje o danych uwzględniają również dodane usługi i biblioteki. Nie kopiujemy opisu prywatności z innego produktu bez sprawdzenia rzeczywistego przepływu. Uzgodnione dokumenty oraz wpisy sklepu powinny opisywać ten sam sposób działania; kwestie prawne firma weryfikuje osobno.
Wersja próbna pomaga przed publicznym startem.
Tester powinien wykonać zadanie na odpowiednim urządzeniu, korzystając z uzgodnionej wersji. Sprawdzamy konto, dane, uprawnienia systemowe i warunki sieciowe istotne dla produktu. Sam fakt instalacji nie potwierdza poprawności rezerwacji ani komunikacji z serwerem.
Apple udostępnia TestFlight do zbierania uwag z wersji beta. Google Play ma własne ścieżki testów oraz wymagania dla określonych kont. Dokumentacja Google o nowych kontach osobistych opisuje wymagany proces przed dostępem do produkcji.
Nie przypisujemy tych samych warunków każdemu kontu i nie utrwalamy liczby dni jako ogólnej obietnicy terminu. Harmonogram ustalamy po sprawdzeniu aktualnych zasad. Odrębnie zapisujemy testy naszego produktu i kroki wymagane przez platformę.
Ocena sklepu ma własny przebieg.
Zgłoszenie może wymagać informacji pozwalających ocenić funkcje dostępne po zalogowaniu. Przygotowujemy instrukcję i właściwe dane dostępowe do uzgodnionego środowiska, jeśli są potrzebne. Materiał powinien umożliwiać sprawdzenie produktu bez korzystania z rzeczywistych danych klientów.
Apple opisuje zasady oceny w App Review Guidelines. Wymagania poznajemy podczas planowania, ponieważ sposób płatności lub działania niektórych funkcji może wpływać na projekt. Nie zakładamy automatycznej akceptacji każdego zgłoszenia.
Jeśli platforma zgłosi uwagę, trzeba ustalić jej przyczynę i przygotować poprawkę lub wyjaśnienie. Termin publicznej dostępności zależy również od tego procesu. Możemy zaplanować materiały i wykonanie, lecz nie gwarantujemy wyniku ani daty decyzji sklepu.
Publikacja otwiera następny etap.
Po udostępnieniu sprawdzamy główne działanie w produkcji oraz sposób kontaktu użytkownika z obsługą. Firma potrzebuje jasnego kanału zgłoszeń, odpowiedzialności i informacji o wersji. Użytkownicy starszego wydania mogą działać jednocześnie z osobami, które już zaktualizowały produkt.
Zmiany serwera powinny uwzględniać taki okres. Aktualizacja nie zawsze dociera do wszystkich w tym samym momencie. Dlatego rozwój obejmuje współpracę wersji, ponowne testy oraz odpowiednie materiały sklepu przy kolejnych wydaniach.
Przed startem ustalamy oddzielnie zakres utrzymania, koszty zewnętrznych usług i sposób realizacji nowych funkcji. Poradnik utrzymania pokazuje, co zaplanować, aby produkt nie kończył się na pierwszym opublikowanym wydaniu.
Jaką decyzję podjąć dalej?
Dla planu sprawdzenia wyjątków i całego przebiegu przeczytaj Testowanie aplikacji przed uruchomieniem.
W budżecie po uruchomieniu uwzględnij Koszt utrzymania aplikacji po wdrożeniu.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Aplikacje na iOS.