Zbiorczy upload zlokalizowanych zrzutów ekranu do obu sklepów

Jesteś w trakcie wydania. Zrzuty ekranu są gotowe. Teraz trzeba je umieścić w obu sklepach, w każdym obsługiwanym języku, w każdym rozmiarze urządzenia wymaganym przez dany sklep. To jest ten fragment procesu, przed którym nikt nie ostrzega — i moment, w którym ludzie po cichu wpisują w wyszukiwarkę coś w stylu "bulk upload localized screenshots app store connect / google play all languages".

Najpierw uczciwa odpowiedź, żebyś mógł przestać szukać: żaden ze sklepów nie ma natywnego zbiorczego uploadu obejmującego wiele języków. Wgrywasz pliki osobno dla każdego języka i każdej rodziny rozmiarów urządzeń, w interfejsie webowym, po jednym zbiorze naraz.

Co naprawdę oznacza "brak zbiorczego uploadu"

W App Store Connect otwierasz swoją aplikację, wybierasz wersję, przewijasz do sekcji zrzutów ekranu i przeciągasz pliki PNG do konkretnego slotu typu wyświetlacza — 6.9", 6.5", 13" iPad i tak dalej. Potem przełączasz listę rozwijaną z lokalizacją na kolejny język i robisz to od nowa. Apple pozwala dodać do 10 zrzutów ekranu na typ urządzenia, na lokalizację. Nie ma przycisku "zastosuj do wszystkich języków" dla obrazów.

Google Play Console działa podobnie. W sekcji Main store listing (Grow users → Store presence) wybierasz lokalizację, a następnie wgrywasz zrzuty ekranu do każdej sekcji urządzenia — telefon, tablet 7-calowy, tablet 10-calowy, a opcjonalnie Chromebook, Wear OS, Android TV i nowsze typy. Do 8 na typ urządzenia. Zmieniasz język, powtarzasz.

Jednostką pracy nie jest więc "zestaw zrzutów ekranu". To jeden zbiór = jeden język × jedna rodzina rozmiarów urządzeń, a każdy taki zbiór wypełniasz ręcznie.

Skala tego przeciągania, w liczbach

Policzmy zbiory uczciwie. U Apple normalne zgłoszenie wypełnia co najmniej rodzinę wyświetlaczy iPhone i rodzinę wyświetlaczy iPad — powiedzmy 2, więcej, jeśli trzymasz osobny zestaw dla 6.5" iPhone obok 6.9". W Play normalne zgłoszenie wypełnia telefon plus dwa rozmiary tabletu — powiedzmy 3, więcej, jeśli dodasz Chromebook albo Wear OS.

• Jeden język, oba sklepy: mniej więcej 2 zbiory Apple + 3 zbiory Play = 5 ręcznych uploadów.
• Dziesięć języków: około 20 + 30 = 50 zbiorów do wypełnienia, każdy mieści do 8–10 obrazów.
• Pięćdziesiąt języków: około 100 + 150 = 250 osobnych uploadów metodą przeciągnij i upuść, zanim jeszcze sprawdzisz, czy właściwy obraz trafił do właściwego slotu.

Trzydzieści minut przeciągania na lokalizację to liczba, którą ludzie podają nie bez powodu. Przy dowolnej realnej liczbie języków przestaje to być zadanie, a staje się popołudniem — popołudniem, które powtarzasz przy każdym kolejnym wydaniu.

Dwie jedyne ścieżki automatyzacji

Jeśli chcesz całkowicie pominąć interfejs webowy, są dokładnie dwie wspierane drogi, po jednej na sklep:

• App Store Connect API. Zasób screenshots pozwala programowo utworzyć zbiór i wgrać obrazy dla danej lokalizacji oraz typu wyświetlacza urządzenia. Uwierzytelniasz się kluczem API i wysyłasz obrazy dla każdego języka i rodziny wyświetlaczy.
• Google Play Developer API. Metoda edits.images.upload wgrywa jeden obraz określonego języka i typu (phoneScreenshots, sevenInchScreenshots, tenInchScreenshots i tak dalej) do oczekującej edycji, którą następnie zatwierdzasz.

Większość zespołów nie korzysta z tych API bezpośrednio. Używają fastlane jako warstwy nad nimi: deliver (dostępny też jako upload_to_app_store) obsługuje App Store Connect API, a supply (upload_to_play_store) obsługuje Play Developer API. Supply potrafi nawet uruchomić kilka wątków uploadu naraz, żeby wysyłać zlokalizowane obrazy równolegle. To jest prawdziwy "zbiorczy upload" — to pętla API, a nie przycisk w panelu.

Warto uczciwie powiedzieć o koszcie: fastlane oznacza narzędzia Ruby, plik fastfile, dane uwierzytelniające API sklepu i (po stronie Apple) zwykłą hydraulikę podpisywania kodu i symulatora. Opłaca się, gdy publikujesz często. Dla aplikacji, która zgłasza się kilka razy w roku, uruchomienie tego tylko po to, by wgrać obrazy, może być więcej pracy niż samo przeciąganie, które ma zastąpić. Jeśli już go używasz do buildów, dodanie kroku ze zrzutami ekranu jest niemal darmowe.

Prawdziwym wąskim gardłem jest źródło zrzutów ekranu

Zauważ, że każda z powyższych ścieżek zakłada, że pliki już istnieją — poprawnie zeskalowane, po jednym zestawie na rodzinę urządzeń, przetłumaczone dla każdego języka. To jest tak naprawdę trudna część. App Store Connect API i Play Developer API przenoszą gotowe obrazy; nie projektują ich, nie zmieniają ich rozmiaru i nie tłumaczą podpisów. Jeśli tworzysz 50 wariantów językowych w 5 rozmiarach urządzeń ręcznie w narzędziu graficznym, upload nigdy nie był twoim wąskim gardłem.

To jest luka, którą wypełnia Mokbi. Budujesz jeden projekt, a on renderuje każdy rozmiar urządzenia i każdy z 50 języków z tego jednego źródła — podpisy przetłumaczone, układ dopasowany na nowo, każda ramka wyeksportowana w dokładnych wymiarach pikselowych oczekiwanych przez slot danego sklepu. Wynikiem jest partia: uporządkowany komplet plików lokalizacja × urządzenie, nazwany i zorganizowany, gotowy do wrzucenia do właściwych zbiorów.

Publikacja w obu sklepach jednym kliknięciem

Mokbi rozwiązuje dokładnie ten problem. Budujesz jeden zestaw, a on renderuje każdy język × każdy rozmiar urządzenia i publikuje je w obu sklepach — wysyła bezpośrednio do Google Play przez Play Developer API i przygotowuje zestawy w App Store Connect, gotowe do twojego zatwierdzenia. Apple wymaga ostatecznego kliknięcia Submit i przeglądu, więc to ostatnie kliknięcie zostaje po twojej stronie; wszystko przed nim jest już zrobione. Żadnego ręcznego uploadu język po języku, urządzenie po urządzeniu.

Jeśli już używasz fastlane albo API sklepów we własnym CI, te same wyeksportowane pliki wchodzą prosto do deliver i supply. Tak czy inaczej projekt, zmiana rozmiaru i tłumaczenie na 50 języków są zrobione za ciebie — a teraz publikacja też.

Workflow, który naprawdę oszczędza popołudnie

1. Zaprojektuj raz. Zbuduj karuzelę jednorazowo w edytorze.
2. Wyeksportuj zbiorczo całą macierz. Każdy rozmiar urządzenia × każdy język, w dokładnych wymiarach sklepowych, w jednym eksporcie.
3. Opublikuj w obu sklepach. Mokbi wysyła zestawy do Google Play i przygotowuje je w App Store Connect do twojego ostatecznego zatwierdzenia — albo przekaż pliki fastlane deliver/supply, jeśli prowadzisz własne CI.
4. Przy kolejnym wydaniu, wyeksportuj ponownie i powtórz. Zmień projekt raz, wygeneruj ponownie całą macierz, wgraj jeszcze raz.

Liczby, które się liczą: liczba zbiorów się nie zmienia, ale czas na zbiór drastycznie się skraca, gdy wrzucasz gotowy, poprawnie zeskalowany plik zamiast najpierw go projektować i skalować. To jest różnica między popołudniem a przerwą na kawę.

Co przeczytać dalej

• Wgrywanie zrzutów ekranu przez App Store Connect API
• Google Play Developer edits API dla stron sklepowych
• Lokalizacja zrzutów ekranu App Store na wszystkie 50 języków

Otwórz edytor →