Скриншоти вирішують долю встановлення ще до того, як користувач встигає прочитати опис. У пошуковій видачі App Store видно три перші кадри — вони формують перше враження і несуть близько 70% конверсійної ваги всієї сторінки листингу. При цьому це один із небагатьох елементів ASO, який можна змінити за день і виміряти за тиждень.
У 2026 році обидві платформи оновили лінійку підтримуваних пристроїв, і вимоги до розмірів знову змінилися. Цей посібник охоплює актуальні технічні специфікації App Store і Google Play, логіку побудови конверсійної послідовності та практичні рішення — від вибору формату до локалізації та A/B-тестування.
Скриншоти App Store і Google Play у 2026 році: роль у листингу
Скриншоти — не просто ілюстрації до тексту. Вони працюють одночасно на двох рівнях: візуальний пітч у видачі пошуку (до переходу на сторінку додатку) і доказова база на самій сторінці листингу.

В App Store перші три скриншоти видно безпосередньо в результатах пошуку без додаткового скролу. Користувач бачить їх поряд із назвою і рейтингом додатку, не переходячи на сторінку. У Google Play першим показується промо-відео (якщо воно є), потім скриншоти. Різниця у відображенні впливає на стратегію: в App Store кожен із перших трьох кадрів має працювати як автономний аргумент на користь встановлення, у Google Play — посилювати меседж відео або брати на себе його роль за відсутності.
Скриншоти не є прямим фактором ранжування в алгоритмах сторів — алгоритми не читають зображення напряму. Але вони впливають на конверсію з перегляду у встановлення (CVR), а CVR — один із сигналів, який алгоритми враховують при оцінці релевантності додатку. Схема проста: кращі скриншоти дають вищу конверсію, вища конверсія — побічно кращі позиції в пошуку. Це не гарантований прямий ефект, але вимірюваний важіль.
Скриншоти — один із небагатьох елементів листингу з коротким циклом зворотного зв'язку: змінив, запустив тест, отримав дані за тиждень. Саме тому робота з ними починається з технічних вимог — вони оновлюються разом із пристроями, і помилка тут перекреслює все інше.
Вимоги App Store до скриншотів 2026
Apple оновлює специфікації в міру виходу нових пристроїв. Нижче — актуальні дані з офіційної документації App Store Connect.
Технічні правила
- Формати: JPEG (.jpeg / .jpg) або PNG
- Прозорість (alpha-канал): не допускається
- Максимум скриншотів: від 1 до 10 на кожен тип пристрою
- Орієнтація: портретна або ландшафтна — залежно від орієнтації додатку
Розміри для iPhone
| Дисплей | Орієнтація | Розмір (px) |
| 6.9" (iPhone Duo/Air, 18/17/16 Pro Max, 15/16 Plus, 14 Pro Max) | Портрет | 1320 × 2868 / 1290 × 2796 / 1260 × 2736 px |
| 6.9" | Ландшафт | 2868 × 1320 / 2796 × 1290 / 2736 × 1260 px |
| 6.5" (iPhone 14 Plus, 13/12/11 Pro Max, XS Max, XR, 11) | Портрет | 1284 × 2778 |
| 6.5" | Ландшафт | 2778 × 1284 |
| 6.3" (iPhone 18/17/16/15 Pro, 14 Pro, 16, 15) | Портрет | 1179 × 2556 або 1206 × 2622 |
| 6.3" | Ландшафт | 2556 × 1179 або 2622 × 1206 |
| 6.1" (iPhone 17e, 16e, 14, 13, 12, 11 Pro та ін.) | Портрет | 1170 × 2532 / 1125 × 2436 / 1080 × 2340 |
| 5.5" (iPhone 8/7/6S Plus) | Портрет | 1242 × 2208 |
| 4.7" (iPhone SE 3/2, 8, 7, 6S, 6) | Портрет | 750 × 1334 |
| 4" (iPhone SE 1st gen) | Портрет | 640 × 1136 |
Ключове правило Apple щодо масштабування: якщо не завантажено скриншоти для конкретного розміру екрана, Apple автоматично масштабує більший формат. Практично це означає: достатньо завантажити скриншоти для 6.9" (або 6.5", якщо 6.9" немає) — вони застосуються до всіх iPhone. Але автомасштабування не гарантує ідеального результату, особливо для ландшафтних скриншотів і додатків з точним компонуванням. Якщо скриншот містить дрібний текст або складну графіку — краще завантажити окремий набір для 6.3" і 6.1".
Що обов'язково: якщо додаток підтримує iPhone, потрібен хоча б один набір скриншотів. Якщо не надано розміри 6.9" — обов'язковий 6.5". Детальніше — у специфікаціях App Store Connect.
Розміри для iPad
| Дисплей | Орієнтація | Розмір (px) |
| 13" (iPad Pro M4/M5, Air M2/M3/M4, 6th–1st gen) | Портрет | 2064 × 2752 або 2048 × 2732 |
| 13" | Ландшафт | 2752 × 2064 або 2732 × 2048 |
| 12.9" (iPad Pro 2nd gen) | Портрет | 2048 × 2732 |
| 11" (iPad Pro, Air, mini A17 Pro та ін.) | Портрет | 1488 × 2266 / 1668 × 2420 / 1668 × 2388 / 1640 × 2360 |
| 10.5" (iPad Pro, Air 3rd gen, iPad 7–9th gen) | Портрет | 1668 × 2224 |
| 9.7" (iPad Pro, Air, Air 2, mini 2–5th gen) | Портрет | 1536 × 2048 |
Що обов'язково: якщо додаток працює на iPad, потрібен мінімум один набір скриншотів iPad. Скриншот для 13" є базовим — інші масштабуються від нього.
Інші платформи Apple
| Платформа | Розмір (px) |
| Mac | 1280×800, 1440×900, 2560×1600 або 2880×1800 |
| Apple TV | 1920×1080 або 3840×2160 |
| Apple Vision Pro | 3840×2160 |
| Apple Watch (Ultra 4/3) | 422×514 |
| Apple Watch (Series 12/11/10) | 416×496 |
| Apple Watch (Series 9–7) | 396×484 |
Вимоги Google Play до скриншотів 2026
На відміну від App Store, Google Play не масштабує скриншоти автоматично — для кожного типу пристроїв потрібен окремий набір. При цьому обмеження щодо контенту суворіші, а Feature Graphic — обов'язковий елемент, аналога якого у Apple немає. Актуальні вимоги — в офіційній довідці Google Play Console.
Загальні технічні вимоги
- Формати: JPEG або PNG 24-bit (без alpha-каналу)
- Розмір файлу: максимум 8 MB на скриншот
- Розмір сторін: мінімум 320 px, максимум 3840 px; довга сторона не може перевищувати коротку більш ніж у 2 рази (співвідношення від 1:2 до 2:1)
- Мінімальна кількість для публікації: 2 скриншоти (для смартфонів)
Вимоги за типами пристроїв
| Пристрій | Рекомендований розмір | Орієнтація | Кількість | Примітка |
| Смартфон | 1080 × 1920 px | Портрет (9:16) | До 8 | Мінімум 2 для публікації |
| Смартфон | 1920 × 1080 px | Ландшафт (16:9) | До 8 | За орієнтацією додатку |
| Планшет 7" | 1080 × 1920 px | Портрет | До 8 | Опціонально, але рекомендується |
| Планшет 10" | 1200 × 1920 px | Портрет | До 8 | Опціонально, але рекомендується |
| Великий екран (tablets 1080+ px, Chromebook) | 1080–7680 px | 16:9 або 9:16 | Мінімум 4 | Обов'язковий для Large Screen |
| Wear OS | 384 × 384 px | 1:1 | Мінімум 1 | Без рамок і прозорих фонів |
| Android TV | Стандартний TV-формат | 16:9 | Мінімум 1 | Обов'язковий для TV-додатків |
| Android XR | 3840 × 2400 px (мін. 1920×1200) | 8:5 | 4–8 | Для XR-додатків |
| Android Automotive | 800 × 1280 (портрет) / 1024 × 768 (ландшафт) | Обидва | По 2+ | Тільки системні образи |
Feature Graphic
Feature Graphic — обов'язковий банер на сторінці листингу: 1024 × 500 px, JPEG або PNG без прозорості. Він відображається вгорі сторінки і використовується, коли Google обирає додаток для редакційних добірок. Це не скриншот — це окремий елемент. За наявності промо-відео Feature Graphic стає його обкладинкою. Якщо він не завантажений або застарів, промо-відео не відображається коректно.
Обмеження контенту Google Play
Google Play явно забороняє у скриншотах: текст із закликом до дії (CTA), згадування знижок або тимчасових акцій, зображення реальних пристроїв (рамки пристроїв — на розсуд розробника), текст, що займає понад 20% площі зображення. Це суворіше, ніж у Apple, — враховуємо при розробці креативів.
App Store проти Google Play: ключові відмінності
| Параметр | App Store | Google Play |
| Обов'язковий базовий розмір | 6.5" або 6.9" iPhone | Смартфон (мін. 2 скриншоти) |
| Макс. скриншотів | 10 на пристрій | 8 на пристрій |
| Відео | App Preview до 30 сек (видно в пошуку) | YouTube-посилання (видно на сторінці) |
| Показ у пошуку | 3 перших скриншоти | Відео або перший скриншот |
| Текст на скриншоті | Без жорстких обмежень | Максимум 20% площі |
| Масштабування | Автоматичне від старшого розміру | Немає автомасштабування |
| Feature Graphic | Немає аналога | 1024 × 500 px (обов'язковий) |
| Прозорість | Не допускається | Не допускається |
| Рамки пристроїв | На розсуд | На розсуд (без реальних пристроїв) |
Принципова різниця — в тому, що бачить користувач до переходу на сторінку. App Store показує в пошуковій видачі три скриншоти горизонтально — вони конкурують один з одним за погляд серед результатів. Google Play показує лише перший скриншот (або превью відео). Це змінює логіку розстановки акцентів: для App Store критично вдарити по всіх трьох позиціях одразу, для Google Play — зробити перший кадр максимально точним.
Як це виглядає на практиці: приклади App Store vs Google Play
Різниця між платформами стає очевиднішою на конкретних прикладах.
Uber

В App Store — темний фон, жирна лаконічна типографіка: «GO ANYWHERE» на всю ширину великими літерами на чорному. Перший кадр — реальний UI з картою і даними про водія, без ілюстрацій. Драматична подача, мінімум слів, максимум упевненості. Додаток не пояснює — він стверджує.
У Google Play — ілюстративний стиль на світлому кремовому фоні. Перший кадр — повна сервісна сітка (Ride, Food, Grocery, Pharmacy та ще кілька), яка одразу показує ширину екосистеми. Далі — «Get Anywhere» з кольоровою графікою і «Rides in a few taps» з реальним екраном маршруту. Логіка: спочатку масштаб пропозиції, потім — простота дії. Якщо App Store говорить з користувачем мовою дії та впевненості, то версія Google Play — мовою lifestyle і охоплення.
Camera360

В App Store — темний редакційний стиль, що відсилає до глянцевого журналу: великі портрети з гарним світлом, темні фони. При цьому суто емоційної подачі немає: на кожному кадрі видно конкретні інструменти (Contour & Highlight, AI Dental Beauty). Продається результат, а підкріплюється він інструментом.
У Google Play — святковий lifestyle-формат з теплою золотистою палітрою. Контент вибудований навколо сезонних AR-фільтрів: Party Hat, Party Glasses, New Year's Bunny — портрети в стікерах на теплому фоні. Жодного утилітарного UI — лише атмосфера та емоція. Це усвідомлена сезонна стратегія: замість показу інструментів платформа продає привід.
Що це означає на практиці
Не копіюємо скриншоти між платформами — адаптуємо. Для App Store критична емоція і сила перших трьох кадрів. Для Google Play важливіше пояснити сценарій і закрити заперечення. Той самий додаток, дві різні розмови з користувачем.
Скільки скриншотів завантажувати?
Технічні ліміти задають стелю, а конверсійна логіка визначає оптимальну кількість.
В App Store максимум — це 10 скриншотів на пристрій. Більшість успішних додатків використовують 5–8. Менше п'яти може виявитися втраченою можливістю показати цінність або розвіяти сумніви користувачів. Більше восьми виправдано лише при багатій функціональності або висококонкурентній ніші, де потрібно закрити більше питань перед встановленням.
У Google Play ліміт — 8 скриншотів на тип пристрою. Використання всіх 8 слотів для смартфонів корелює з кращою видимістю в пошуку. Особливо важливо заповнювати слоти для планшетів і великого екрана — туди доходить менша кількість конкурентів, і це справді конкурентна перевага в tablet search.
Практичне правило: не добиваємо скриншоти заради кількості. Кожен із них має додавати аргумент, якого немає в попередніх. Якщо його немає — слот краще залишити порожнім.
Визначившись із кількістю, наступне питання — в якому порядку ці кадри мають переконувати користувача.
Як будувати конверсійну послідовність скриншотів
Більшість команд думають про скриншоти як про набір картинок — і це хибна модель. Скриншоти — послідовний наратив, де кожен кадр спирається на попередній і рухає користувача до рішення.

Кадр 1 — Ціннісна пропозиція (Value Promise)
Формулює головний результат, який отримає користувач. Не описує додаток — обіцяє результат. Приклад для трекера звичок: не «Додаток для трекінгу звичок», а «21 день — і звичка закріпиться назавжди». Перший кадр має читатися за секунду без збільшення і працювати навіть у мінімальному розмірі превью у видачі App Store. Він має бути зрозумілим поза контекстом — без назви додатку поруч.
Хороший орієнтир — Notion: перший кадр «Your life, beautifully organized» і один чистий екран. Жодних пояснень, жодного UI-туру — лише результат.
Кадри 2–3 — Сценарій використання і диференціатор
Кадр 2 показує, як саме працює додаток: основна функція в дії, конкретний інтерфейс. CapCut на другому кадрі не розповідає про відеоредактор — він показує одну дію (AutoCut), зрозумілу без тексту.
Кадр 3 — те, чого немає у конкурентів: унікальна функція, швидкість, конкретний результат. Саме ці три кадри видно в пошуку App Store без скролу, і вони несуть близько 70% конверсійної ваги за даними галузевого дослідження.
Кадри 4–6 — Розширення аргументації
Додаткові сценарії використання, вторинні функції, інтеграції з іншими сервісами. Тут уже можна деталізувати і працювати із запереченнями: «чи працює це без інтернету?», «чи підтримує кілька пристроїв?». Кожен кадр — одне заперечення і одна відповідь.
Кадри 7–10 — Довіра і соціальні докази
Рейтинги, згадки в пресі, кількість користувачів, галузеві нагороди. Працюють як фінальний аргумент для вже зацікавленого, але ще не вирішеного користувача. Не ставимо сигнали довіри на початок — вони посилюють наявний інтерес, але не створюють його з нуля.
Найкращі практики дизайну скриншотів для ASO
Структура послідовності задає логіку — деталі дизайну визначають, наскільки переконливо вона працює. Типографіка, контраст, колір і узгодженість бренду додають або забирають конверсію в кожному кадрі.
Типографіка і текст
Підписи — максимум 5 слів, розмір шрифту від 60 pt і вище у вихідному макеті. Простий тест: зменшуємо скриншот до розміру плитки в пошуковій видачі App Store — якщо текст перестає читатися, він не працює. Один скриншот — один меседж. Без дрібного тексту, виносок і багатослівних пояснень.
Підписи мають бути активними, а не описовими. «Плануй день за 2 хвилини» працює краще, ніж «Функція планування дня». Активний стан, дієслово дії, конкретний результат. Уникаємо абстракцій — «зручний», «потужний», «інтуїтивний» не несуть інформації і не переконують.
Ієрархія і контраст
Один скриншот — одна ідея. Не потрібно показувати весь UI — достатньо одного ключового елементу з акцентом. Високий контраст між фоном і текстом необхідний не лише для краси, але й для доступності (орієнтуємося на WCAG AA як мінімум). Візуальне перевантаження — конверсійний вбивця: три елементи UI, два підписи і іконка на одному екрані створюють когнітивний шум, з якого користувач просто іде.
Колірна схема і темна тема
Розробляємо скриншоти у двох варіантах — світлому і темному. Темна тема стала стандартним очікуванням мобільної аудиторії. Якщо додаток підтримує обидва режими, скриншоти мають це відображати. Яскраві світлі фони на телефонах у темному режимі виглядають застарілими — і користувач це відчуває ще до встановлення.
Узгодженість з брендом
Усі скриншоти — єдина візуальна система: шрифти, кольори, стиль ілюстрацій. Різнобій між кадрами сприймається як недбалість. Використовуємо один майстер-файл із загальними компонентами для всієї серії — це скорочує час оновлення і виключає випадкові розбіжності.
Автентичність замість глянцю
Користувачі все краще розпізнають постановочні кадри — і все гірше на них реагують. Скриншоти з реальним інтерфейсом і живими сценаріями нерідко конвертують краще ідеально відполірованих. Студійна стерильність створює дистанцію там, де потрібна довіра.
Це не означає робити недбало. Це означає показувати додаток у реальному контексті: справжній UI, зрозумілий сценарій, без декорацій заради декорацій. Користувач має впізнати у кадрі себе — а не рекламний макет.
Зберігаємо робочі файли
Кожен скриншот має мати вихідний макет з окремими шарами: фон, UI, текстовий підпис, рамка пристрою. Це скорочує час оновлення при редизайні додатку або A/B-тесті з одним змінним елементом з кількох днів до кількох годин.
Рамки пристроїв, UI-скриншоти і lifestyle-зображення
Окрім дизайну кадрів, важливо вирішити базове питання: у якому вигляді показувати сам додаток. Три основних підходи вирішують різні завдання.
UI-орієнтовані скриншоти — прямий показ інтерфейсу з мінімальними декоративними елементами. Працюють для утилітарних додатків, де функціональність є головним аргументом: фінансові інструменти, продуктивність, B2B-рішення. Користувач бачить саме те, з чим буде працювати, і приймає рішення на основі реального інтерфейсу.
Рамки пристроїв — скриншот у обрамленні моделі телефону або планшета. Допомагають користувачу візуалізувати додаток на своєму пристрої. Важливо: у Google Play не можна використовувати зображення реальних пристроїв (фото телефонів від виробників), допустимі лише стилізовані або абстрактні рамки. В App Store обмежень немає, але використання фірмової айфон-графіки без дозволу Apple — юридично чутлива територія.
Lifestyle-зображення — поєднання UI і реального контексту використання: людина з телефоном у кав'ярні, тренування з фітнес-додатком, робочий простір із корпоративним інструментом. Посилюють емоційний резонанс для споживчих додатків і ігор. Потребують балансу: якщо контекст перевантажує і інтерфейс ледве помітний — цінність втрачається. Користувач бачить гарну фотографію, але не розуміє, що саме робить додаток.
Складені креативи (composite) — комбінація елементів UI, рамок і фонових сцен. Найгнучкіший формат. Характерний для ігрових додатків і категорії lifestyle, де продається не інструмент, а досвід і атмосфера. Вимагає найбільших ресурсів на виробництво, але дає максимальний творчий контроль над наративом.
Що обрати — залежить від категорії, аудиторії і конкурентного контексту. Аналіз топ-додатків у нашій категорії допомагає визначити, який підхід конвертує краще в конкретній ніші, не витрачаючи бюджет на сліпі експерименти.
Локалізація скриншотів
Коли формат візуалу обрано, наступна змінна — ринок. Локалізація — не переклад підписів, а адаптація всього візуального наративу під культурний контекст.
Різні ринки реагують на різну візуальну мову. В Азії працюють насичені кольори і динамічні композиції, в Європі — мінімалізм і чисті лінії, в арабських країнах критично важливі напрямок тексту і вибір символіки.
Temu використовує різні колірні рішення і образи для Кореї та Португалії — при тому що основний посил один і той самий. Instagram адаптує типографіку і акценти для США і Німеччини, не змінюючи глобальну концепцію бренду. Суть локалізації не в перекладі підписів, а в тому, щоб користувач у цільовому регіоні побачив знайомий візуальний контекст.
Японська аудиторія очікує щільний інформаційний шар і детальний UI — мінімалізм там сприймається як нестача функціональності. Американський ринок реагує на чистий дизайн і чітку ціннісну обіцянку. Латинська Америка чутлива до емоційних образів і соціальних доказів. Німеччина очікує точності і технічної конкретики.
Практичні кроки:
- Перекладаємо текст з урахуванням довжини рядка — німецька і фінська значно довші за англійську і не вміщаються в той самий макет без перекомпонування.
- Адаптуємо референсні образи: імена персонажів, приклади транзакцій, локалізований UI (формат дати, валюта, адреси).
- Перевіряємо візуальні образи на культурну нейтральність — жести, кольори і символи мають різне значення в різних регіонах.
- Перевіряємо кириличні та арабські шрифти — вони потребують окремої верстки через різні системи письма (RTL для арабської).
- Завантажуємо локалізовані скриншоти у відповідні локалі App Store / Google Play, а не лише в дефолтний листинг.
App Store дозволяє завантажувати окремі набори скриншотів для кожної локалізації. Google Play — аналогічно. При обмежених ресурсах починаємо локалізацію зі скриншотів для ринків із найбільшим потенціалом конверсії — високий трафік і низька конкуренція в сукупності, а не лише за абсолютним обсягом пошуку.
Тестування скриншотів і вимірювання конверсії
Створити хороші скриншоти — половина роботи. Друга — зрозуміти, який варіант конвертує краще. Обидві платформи дають для цього вбудовані інструменти.
App Store Product Page Optimization (PPO) — інструмент A/B-тестування в App Store Connect. Дозволяє тестувати альтернативні іконки, скриншоти і коротке описання. Трафік ділиться 50/50 між контрольною і тестовою версією. Статистично значущі результати вимагають часу — не завершуємо тест раніше, ніж наберемо достатню вибірку. Мінімальний виявлюваний ефект — близько 5–8% різниці в CVR.
Google Play Store Listing Experiments — аналогічний інструмент у Google Play Console. Тестує іконку, скриншоти, Feature Graphic, коротке і повне описання. Дозволяє задати відсоток трафіку на тест (від 5% до 50%) і відстежувати динаміку в реальному часі.
Тестуємо один елемент за раз. Якщо одночасно змінити підпис, порядок кадрів і колірну схему — не зрозуміємо, що саме спрацювало.
Головне правило — перевіряти гіпотези, а не змінювати все підряд. Формулюємо конкретне припущення перед запуском: «додавання людини в перший кадр збільшить CTR» або «темний фон дасть вищу конверсію в нашій категорії». Так ми розуміємо, чому спрацювало, і можемо масштабувати висновок, а не просто зафіксувати результат.
Починаємо з першого кадру — він несе найбільшу конверсійну вагу, і будь-яке його покращення дає максимальний ROI. Після того як він оптимізований, переходимо до третього, потім до другого.
Метрики, які важливо відстежувати:
- Impressions → Tap-Through Rate (CTR) — скриншоти насамперед впливають тут, у пошуковій видачі, до переходу на сторінку
- Store Listing Visits → Installs (CVR сторінки) — загальна конверсія листингу
- CVR за окремими джерелами трафіку — пошук, браузинг і редакційні розділи реагують на скриншоти по-різному
- Retention rate перших днів — непрямий індикатор відповідності скриншотів реальному досвіду. Якщо скриншоти обіцяють більше, ніж дає додаток, retention падає незалежно від CVR
Якщо тест не набирає достатній обсяг — результати статистично ненадійні. Не робимо висновків на 200–300 встановленнях.
Чеклист перед завантаженням скриншотів
Використовуємо перед кожним оновленням скриншотів у магазинах.
Технічні параметри
- Розміри відповідають актуальним вимогам платформи (App Store Connect / Google Play Console)
- Формат — JPEG або PNG без alpha-каналу
- Відсутність прозорих областей
- Розмір файлу в межах ліміту (Google Play — до 8 MB)
Зони безпеки і читабельність
- Ключовий текст і UI-елементи поза зонами обрізки (rounded corners на iPhone, Dynamic Island)
- Текст читається при зменшенні до розміру превью в пошуковій видачі
- Контраст фону і тексту достатній для доступності (перевірити WCAG AA)
Послідовність і зміст
- Перший скриншот формулює ціннісну пропозицію, а не описує додаток
- Кожен наступний кадр додає новий аргумент
- Немає повторення одного і того ж меседжу в різних кадрах
- Підписи короткі (до 5 слів), в активному стані
Локалізація
- Завантажено локалізовані версії для ключових ринків
- Текст на локальних мовах вміщається в макет
- Культурний контекст перевірено для нестандартних ринків
Відповідність вимогам платформи
- Для Google Play: текст не перевищує 20% площі зображення
- Для Google Play: немає зображень реальних пристроїв (фото)
- Немає тимчасових акцій, знижок, CTA-мови у скриншотах Google Play
- Відсутні згадки, що порушують гайдлайни платформ
Експорт
- Фінальний експорт у потрібному розрізненні без артефактів стиснення
- Збережено робочий файл з вихідними шарами для майбутніх правок
- Архів попередньої версії скриншотів — на випадок відкату
Типові помилки у скриншотах додатків
Навіть при правильних розмірах і сильній концепції легко пропустити деталі, які зводять нанівець ефект. Ось помилки, які трапляються найчастіше.
Перевантажений перший кадр. Три елементи UI, два підписи і іконка — користувач нічого не розуміє за секунду перегляду. Перший кадр має бути простішим, а не інформативнішим за всі інші.
Скриншоти, не оновлені після редизайну. Старий UI на скриншотах при актуальному додатку руйнує довіру ще до натискання кнопки встановлення. Невідповідність між тим, що бачили на скриншоті, і тим, що відкрилося після встановлення — одне з головних джерел ранніх видалень.
Скриншоти-описи замість аргументів. «Розумний трекер витрат» — опис. «Дізнайтеся, куди йдуть 30% бюджету» — аргумент. Перше інформує, друге переконує. Різниця в CVR при такому переході нерідко становить 10–20%.
Ігнорування планшетних скриншотів. У Google Play і App Store більшість розробників не завантажують оптимізовані скриншоти для iPad і планшетів Android. Автомасштабування дає посередній результат: вертикальний iPhone-скриншот, розтягнутий під iPad, виглядає непрофесійно. При цьому в tablet search конкуренція нижча — це малозатратний спосіб отримати видимість у сегменті з високою платоспроможністю.
Відсутність темної теми. Скриншоти лише у світлому режимі при додатку з підтримкою темної теми — втрачений аргумент. Користувачі, які живуть у темному режимі, бачать невідповідність між скриншотами і реальним досвідом.
Надто дрібний текст. Текст, читабельний у Figma при 100%, часто стає нечитабельним у плитці пошуку App Store (близько 300–400 px ширини на екрані телефону). Перевіряємо макет на реальних пристроях, а не лише в редакторі.
Однакові скриншоти для всіх країн. Англійська як дефолт для глобального запуску — прийнятно на старті, але не оптимально. Навіть мінімальна локалізація — переклад підписів і заміна UI-прикладів на локальний контекст — дає вимірюваний приріст CVR на нецільових ринках.
Як ASOMobile допомагає аналізувати конкурентів і керувати видимістю
Помилки легше помічати на чужих прикладах — і корисніше виправляти на основі даних, а не інтуїції. Зрозуміти, що працює в категорії, можна через аналіз конкурентних скриншотів: які перші кадри вони обирають, як будують послідовність, де тестують ціннісну пропозицію. Вручну це займає години і дає лише миттєвий знімок без історії змін.

ASOMobile дозволяє відстежувати зміни в листингах конкурентів: коли вони оновлювали скриншоти, що змінили в метаданих, як змінювалися позиції після оновлення. Зв'язка «зміна скриншотів → динаміка позицій і оцінок» дає гіпотези для власних тестів без сліпого копіювання. Ми не копіюємо рішення — ми розуміємо, чому воно спрацювало, і адаптуємо під свій контекст.

Інструменти моніторингу ключових слів показують, під які запити оптимізовані скриншоти конкурентів через текст у кадрах, і де є незайняті тематичні ніші для диференціації. Це дозволяє будувати візуальну стратегію не на наздоганяння лідерів, а на зайняття незайнятих ніш.
Підсумок
Скриншоти — найбільш керований елемент листингу. На відміну від рейтингу або кількості відгуків, їх можна змінити за день і виміряти ефект за тиждень. Це робить їх одним із небагатьох інструментів ASO з коротким циклом зворотного зв'язку — змінив, перевірив, масштабував.
Вимоги платформ у 2026 році оновилися — у App Store і Google Play різні базові формати, різна логіка масштабування і різні обов'язкові елементи. Автомасштабування працює, але не замінює набір, зібраний під конкретний пристрій.
Конверсійна механіка незмінна: перші три кадри — ціннісна пропозиція, кейс і диференціатор. Все інше працює на утримання вже зацікавленого користувача. Аналізуємо конкурентів, тестуємо гіпотези через PPO і Store Listing Experiments, локалізуємо для ключових ринків.
Оптимізуйте легко і досягайте успіху 💙
FAQ: Frequently Asked Questions
Базові формати iPhone: 6.9″ — 1320 × 2868 / 1290 × 2796 / 1260 × 2736 px (портрет), 6.5″ — 1284 × 2778 px. Якщо завантажено скриншоти 6.9″, інші розміри Apple масштабує автоматично. Для iPad базовий: 13″ — 2064 × 2752 px або 2048 × 2732 px. Актуальний повний список — в офіційній документації App Store Connect.
Для смартфону: рекомендується 1080 × 1920 px (портрет) або 1920 × 1080 px (ландшафт). Мінімум 2 скриншоти для публікації, максимум 8 на тип пристрою. Формат — JPEG або PNG без прозорості, файл до 8 MB. Текст не повинен займати більше 20% зображення. Feature Graphic — 1024 × 500 px — обов’язковий.
До 10 скриншотів на кожен підтримуваний тип пристрою (iPhone і iPad рахуються окремо). Оптимально для більшості додатків — 5–8 кадрів.
До 8 скриншотів на кожен тип пристрою (смартфон, планшет 7″, планшет 10″ — окремо). Використання всіх 8 слотів для смартфону корелює з кращою видимістю. Для планшетів окремі набори дають перевагу в tablet search.
Прямого впливу на ранжування немає — алгоритми не читають зображення напряму. Але скриншоти впливають на CVR (конверсію з перегляду у встановлення), а CVR — непрямий сигнал якості для алгоритмів. Покращення CVR через оптимізацію скриншотів — один із найшвидших важелів зростання в ASO.
Так, якщо додаток працює на кількох ринках. App Store і Google Play дозволяють завантажувати різні набори для кожної локалізації. Навіть мінімальна адаптація — переклад підписів і заміна UI-прикладів на локальний контекст — дає вимірюваний приріст CVR на нецільових ринках.
В App Store — через Product Page Optimization (PPO) в App Store Connect. У Google Play — через Store Listing Experiments у Google Play Console. Ключові метрики: Tap-Through Rate з пошуку і CVR сторінки листингу. Тест вважається значущим при різниці від 5–8% і достатньому обсязі трафіку (кілька тисяч переглядів).
