O Screenshots.live
Screenshots.live automatyzuje żmudną pracę między kodem mobilnym a App Store. Stworzony przez programistę, który miał dość ręcznego eksportowania tych samych zrzutów ekranu dla 13 lokalizacji w każdym wydaniu.
Kto to buduje?
Eric Isensee — Founder
Inżynier z siedzibą w Niemczech. Buduje Screenshots.live od 2024 roku z naciskiem na powierzchnię API, której deweloperzy faktycznie chcą — konfiguracje YAML, deterministyczne renderowanie i ustawienia domyślne przyjazne dla CI/CD. Wcześniej dostarczał systemy mobilne i backendowe w branży e-commerce, fintech i narzędzi deweloperskich.
Dlaczego Screenshots.live istnieje?
Zrzuty ekranu w sklepach z aplikacjami to najbardziej skuteczne narzędzie marketingowe w świecie mobile — to one decydują, czy użytkownik zainstaluje Twoją aplikację. To także najbardziej pracochłonny element: każde wydanie oznacza ponowne eksportowanie tych samych kompozycji dla iPhone 6,5 cala, iPhone 6,7 cala, iPad 12,9 cala, iPad 11 cali, telefonu Android, tabletu Android 7 cali i tabletu Android 10 cali. Pomnóż przez każdą lokalizację, w której dostarczasz produkt. To 50+ obrazów na wydanie dla aplikacji jednojęzycznej, 600+ dla aplikacji w 12 lokalizacjach.
Ręczny eksport załamuje się pod takim obciążeniem. Projektanci tracą koncentrację. Lokalizacje wypadają z synchronizacji. Wydania się opóźniają. Screenshots.live rozwiązuje to, traktując zrzuty ekranu jak kod: zaprojektuj raz w wizualnym edytorze, renderuj programowo przez API lub wtyczkę Fastlane, dostarcz każdy wariant w jednym uruchomieniu CI.
Dla kogo to jest?
- Deweloperzy mobilni i liderzy techniczni którzy chcą, aby generowanie zrzutów ekranu odbywało się w CI/CD, a nie w backlogu projektanta.
- Specjaliści ASO prowadzący testy A/B i potrzebujący generowania wariantów, które nie wymaga akrobacji w Sketch+Photoshop.
- Niezależni deweloperzy i małe zespoły dostarczający produkty w wielu lokalizacjach bez dedykowanego zespołu projektowego.
- Zespoły marketingowe w firmach SaaS które muszą utrzymywać zasoby sklepowe w synchronizacji ze zmianami w treści produktu.
Jak to budujemy?
Trzy zasady kierują produktem:
- API w pierwszej kolejności. Każda funkcja wizualnego edytora jest również udostępniona jako REST. Szablony, elementy, renderowania, czcionki — wszystkie adresowalne przez klucz API. Jeśli przepływ pracy można wykonać w edytorze, można go wykonać w CI/CD.
- Deterministyczne renderowanie. Ten sam szablon + zmienne za każdym razem produkuje te same piksele. Żadnych zawodnych wyjść LLM w ścieżce renderowania. Kluczowe dla testów zrzutów ekranu opartych na różnicach i artefaktów CI nadających się do przeglądu.
- Domyślne rozgałęzianie lokalizacji. Renderowanie wielojęzyczne to nie flaga funkcji — to sposób, w jaki działa produkt. Jeden szablon, każda obsługiwana lokalizacja, w jednym wywołaniu API.
Gdzie mogę dowiedzieć się więcej?
- Przeczytaj przewodnik Build with AI dotyczący autonomicznych przepływów pracy agentów.
- Sprawdź blog, aby zapoznać się z poradnikami ASO i studiami przypadków automatyzacji.
- Przejrzyj referencję rozmiarów zrzutów ekranu na 2026 rok.