Co możesz zmienić bez nowej wersji aplikacji: Apple vs Google
Zanim dotkniesz wpisu w sklepie, warto odpowiedzieć na jedno pytanie: czy ta edycja będzie mnie kosztować pełne zgłoszenie, czy może zostać opublikowana po cichu? Pomylisz się, a albo utkniesz w kolejce weryfikacji, na którą nie zaplanowałeś czasu, albo założysz, że zmiana jest już na żywo, choć wciąż czeka na zatwierdzenie. Oba sklepy odpowiadają na to pytanie w przeciwny sposób i właśnie ta różnica sprawia, że synchronizowanie wpisów między nimi jest uciążliwe.
Oto uczciwa wersja pole po polu — zaczynając od macierzy, a potem uzasadnienie zasad każdego sklepu, żebyś mógł przewidzieć przypadki, których ta tabela nie wyjaśnia wprost.
Macierz
Każde typowe pole wpisu i to, czego wymaga dany sklep przy jego zmianie. "Nowa wersja / wydanie" oznacza, że sklep traktuje edycję jako część zgłoszenia, które musisz wysłać; "weryfikowane" oznacza, że przed publikacją uruchamiana jest kontrola ręczna lub automatyczna.
| Ikona aplikacji | Główna ikona jest częścią binarki — jej zmiana wymaga nowego builda. Weryfikowana razem z tym buildem. | Ikona sklepowa to zasób wpisu. Brak nowego wydania. Weryfikowana. |
Rzucają się w oczy dwie rzeczy. Apple przepuszcza niemal wszystko przez rekord wersji. Google pozwala, by cały wpis poruszał się samodzielnie. Żaden ze sklepów nie pomija weryfikacji zasobów, które się liczą — słowo "weryfikowane" pojawia się niemal w każdej komórce. Prawdziwe pytanie rzadko brzmi więc "czy to zostanie zweryfikowane", tylko "czy ta edycja ciągnie za sobą zgłoszenie".
Apple: nowy rekord wersji to nie to samo co nowy build
To rozróżnienie, które ludzi myli. W App Store edycja zrzutów ekranu, nazwy, podtytułu, pola słów kluczowych czy opisu tworzy nową wersję Twojego wpisu. Brzmi to tak, jakby to miało zmusić Cię do powrotu do Xcode. Nie musi. Apple automatycznie przenosi bieżące metadane do nowej wersji, a zmiana samych metadanych nie wymaga nowego kodu aplikacji — dołączasz build (App Store Connect nadal go wymaga na wersji) i nie zmieniasz nic w działaniu aplikacji. Edytujesz zaplanowane pola, wysyłasz zgłoszenie i jeden cykl weryfikacji obejmuje je wszystkie.
Warto więc zapamiętać to jako "brak nowego kodu, ale nadal weryfikacja". Bez kompilacji i bez nowych funkcji — ale edycja i tak trafia do App Review i czeka na swoją kolej, zanim stanie się publiczna. Grupuj zmiany razem: skoro jeden rekord wersji może zawierać nowe zrzuty ekranu, przepisany opis, świeży podtytuł i zaktualizowane słowa kluczowe naraz, nie ma powodu poświęcać osobnego cyklu weryfikacji na każdą z nich.
Ikona aplikacji to wyjątek, który rzeczywiście wymaga builda. Główna ikona jest wpieczona w binarkę i z niej pobierana, więc naprawdę nowa ikona oznacza nowy build. To samo dotyczy ikon alternatywnych — muszą być dołączone do aplikacji, by były użyteczne, więc dodanie jednej to build, a nie edycja wpisu.
Dwie furtki Apple
Tekst promocyjny. To jedyne pole, które możesz zmienić bez wersji i bez weryfikacji. Ma 170 znaków, znajduje się nad opisem i aktualizujesz je, kiedy chcesz — przydatne przy wyprzedaży, notce o premierze czy treści zależnej od czasu. Nie wpływa na pozycję w wyszukiwarce i nie jest częścią żadnego zgłoszenia, co jest właśnie powodem, dla którego to najszybsza rzecz do zmiany w sklepie. Jeśli potrzebujesz czegoś na żywo już dziś, to jest to pole, które to umożliwia.
Product Page Optimization. PPO pozwala testować do trzech wariantów zrzutów ekranu, App Preview i ikony względem Twojej aktywnej strony produktu — bez wydawania nowej wersji aplikacji. To najbliższe, co Apple oferuje w kwestii zmiany elementów wizualnych poza zwykłym zgłoszeniem. Dwa zastrzeżenia trzymają to w ryzach: metadane wariantu muszą zostać zatwierdzone, zanim test ruszy (więc to weryfikacja, nie natychmiastowość), a każda testowana ikona musi już być częścią aktualnej binarki aplikacji. PPO zmienia to, co widzą odwiedzający; nie omija weryfikacji.
Google Play: publikacja wpisu bez wydania
Play działa odwrotnie. Twój wpis w sklepie — tytuł, krótki opis, pełny opis, zrzuty ekranu, grafika promocyjna, ikona, wideo promocyjne — można edytować i publikować samodzielnie, bez dołączonego nowego wydania aplikacji. Wprowadzasz zmiany, a one pojawiają się w przeglądzie publikacji jako zmiany gotowe do wysłania do weryfikacji. Wysyłasz je, przechodzą przez weryfikację Google i trafiają na żywo niezależnie od jakiegokolwiek builda.
Kilka rzeczy trzeba doprecyzować, żeby tego nie przesadzić. Zmiany nadal są weryfikowane — weryfikacja Play obejmuje też edycje wpisu, a elementy takie jak nazwa aplikacji czy ikona są sprawdzane, więc to nie jest cicha, natychmiastowa podmiana. A wpis nie może istnieć w oderwaniu od wydanej aplikacji — Play wymaga, by aplikacja miała wcześniejsze wydanie, zanim powstanie publiczny wpis do edycji. Nie da się wypchnąć samodzielnej strony sklepowej dla czegoś, co nigdy nie zostało wydane. Publikacja zarządzana dodaje jeszcze jedną komplikację, o której warto wiedzieć — jeśli jest włączona, zatwierdzone zmiany czekają, aż aktywnie je opublikujesz, co jest funkcją, nie opóźnieniem, gdy się tego spodziewasz.
Asymetria i dlaczego kosztuje Cię czas
Zestaw oba modele obok siebie, a podział jest jasny. Apple wiąże niemal każdą edycję tekstu i obrazu z rekordem wersji i cyklem weryfikacji, a tekst promocyjny i PPO to jedyne sposoby, by to obejść. Google całkowicie odseparowuje wpis od wydania, weryfikuje edycje i publikuje je według własnego harmonogramu, o ile aplikacja już istnieje.
Ta asymetria po cichu kosztuje, gdy prowadzisz oba sklepy. Ten sam odświeżony zestaw zrzutów ekranu to zgłoszenie z nowym rekordem wersji w jednym sklepie i samodzielna aktualizacja wpisu w drugim. Przepisany opis to weryfikowana wersja w Apple i weryfikowana zmiana wpisu w Google. Treść jest ta sama; mechanika już nie, więc zmiana, która na Play jest jedną czynnością, staje się inną czynnością w App Store — i łatwo wysłać jedną, a zapomnieć o drugiej, albo założyć, że coś jest już na żywo w Apple, gdy nadal czeka na weryfikację.
Gdzie pasuje Mokbi
Ta międzysklepowa asymetria to cały powód, dla którego narzędzie do publikacji się opłaca. Mokbi zaczęło jako edytor zrzutów ekranu, ale wpis to tekst i obrazy razem — więc projektuje zestaw zrzutów ekranu i pisze treść wpisu dla obu sklepów w jednym miejscu: nazwa, podtytuł, pole słów kluczowych i opis dla App Store; tytuł, krótki opis i pełny opis dla Play. Otrzymujesz pola, które każdy sklep faktycznie indeksuje, dopasowane do tego sklepu, zamiast jednego bloku tekstu wklejanego dwukrotnie.
Następnie tłumaczy cały wpis — zrzuty ekranu i treść — na 50 języków, więc zmiana wprowadzona raz trafia do właściwego pola na każdym rynku, zamiast pozostać po angielsku we wpisie, który wszędzie indziej jest zlokalizowany. I publikuje: Mokbi wypycha gotowy wpis prosto do Google Play przez Play Developer API oraz przygotowuje go w App Store Connect, gotowy do wysłania — Apple i tak wymaga ostatecznego kliknięcia Submit i przejścia weryfikacji po swojej stronie, co jest zasadą Apple i dokładnie tą asymetrią między sklepami, o której jest ten cały wpis. Ta ostatnia weryfikacja to też moment, w którym zaczynają biec zegary z tego artykułu.