Скриншоты App Store: складной iPhone Ultra в 2026

Вы не должны массово переделывать скриншоты App Store из-за слухов о складном iPhone Ultra. Быстрее и безопаснее сейчас отделить реальные требования App Store Connect от неподтверждённых размеров экрана, подготовить широкие кандидатные кадры и сделать экспорт заменяемым. Финальные изображения стоит выпускать только после официального объявления устройства и обновления документации Apple.

Эта схема подходит вам, если вы готовите осенний релиз iOS-приложения, управляете локализациями, пользовательскими страницами продукта или несколькими наборами маркетинговых материалов. Она также полезна тестировщикам и дизайнерам, которые хотят проверить адаптивный интерфейс без доступа к неизвестному устройству.

Последнее обновление: 8 августа 2026 года. Данные сверены с документацией Apple Developer, справкой App Store Connect и доступными сообщениями о предполагаемом осеннем мероприятии.

Сначала отделите слот App Store от размера экрана

На 8 августа 2026 года в опубликованной Apple таблице требований для iPhone указаны существующие семейства экранов, включая категории 6,9″, 6,5″, 6,3″, 6,1″, 5,5″ и более старые размеры. Для актуального крупного iPhone Apple указывает, например, портретный размер 1 320 × 2 868 пикселей и альбомный размер 2 868 × 1 320 пикселей. Отдельной категории для складного iPhone или режима «развёрнутого экрана» в этой таблице сейчас нет. Это не доказывает, что такая категория не появится позже, но означает: сегодня у вас нет подтверждённого требования создавать отдельный набор. Текущая таблица размеров скриншотов Apple должна быть вашим исходным ориентиром, а не макеты из утечек.

Apple также разрешает загрузить от одного до десяти скриншотов для соответствующего набора. Если интерфейс приложения одинаков на разных размерах, можно предоставить изображения с самым высоким требуемым разрешением — App Store Connect автоматически масштабирует их для меньших вариантов. Это важная причина не дублировать работу заранее: наличие нового физического форм-фактора не означает автоматически появление нового обязательного слота. Правила загрузки скриншотов и превью описывают именно текущий процесс публикации, а не будущие требования к неподтверждённому устройству.

Переделывать сейчас или ждать объявления Apple

Слухи о складном iPhone Ultra и возможном осеннем показе действительно создают короткое окно для подготовки. В публикациях упоминаются iPhone 18 Pro и складная модель, которую СМИ называют iPhone Ultra. Однако название, дата презентации, дата начала продаж и сама схема размещения устройства остаются неподтверждёнными Apple. В одной из публикаций предполагается мероприятие 8 или 9 сентября, а приглашение может появиться 25 или 26 августа; это прогноз, а не календарь релиза. Разбор возможных дат мероприятия и анализ осеннего окна презентации полезны только для планирования дежурства команды, но не для расчёта размеров файлов.

Разделяйте три независимых события:

1. устройство показывают на презентации;
2. разработчики получают SDK, симулятор или реальные параметры;
3. App Store Connect публикует новые категории, размеры или правила проверки.

Между ними может быть задержка. Даже если устройство будет показано в сентябре, это не означает, что в тот же день станет обязательным отдельный набор скриншотов. Также презентация не равна началу продаж: часть сообщений о складной модели допускает разнесённые даты анонса и доступности.

Что можно оставить без изменений

Текущие изображения обычно можно сохранить, если они:

• показывают реальные функции приложения;
• не содержат изображения несуществующего устройства;
• не обещают пользователю режим, которого нет в опубликованной версии;
• не зависят от конкретной формы корпуса;
• остаются читаемыми после масштабирования;
• не привязаны к жёстко заданному числу пикселей внутри самого интерфейса.

Особенно хорошо повторно используются скриншоты редакторов, карточек задач, профилей, поиска, настроек и пошаговых сценариев. Их ценность определяется функцией, а не рамкой телефона. Если первый экран объясняет, какую задачу решает приложение, его не нужно заменять только потому, что в будущем может появиться более широкая область отображения.

Apple рекомендует использовать изображения интерфейса приложения, чтобы показать пользовательский опыт, и советует делать первые один—три кадра максимально понятными, поскольку именно они могут использоваться в результатах поиска, если нет App Preview. Рекомендации Apple по странице продукта поддерживают такой подход: сначала проверяйте смысл и порядок кадров, а не декоративную оболочку вокруг устройства.

Какие приложения стоит готовить к широкому кадру

Не каждому приложению нужен «развёрнутый» скриншот. Предварительная работа оправдана там, где дополнительная ширина может показать реальную пользу:

• редактор кода или текста с панелями;
• аналитическая панель с несколькими показателями;
• файловый менеджер;
• карта с боковой карточкой маршрута;
• читалка с оглавлением и содержимым;
• CRM или рабочее пространство с таблицей;
• приложение для монтажа, рисования или управления проектами.

Плохой кандидат — экран, который просто растягивает один узкий столбец. Если широкая версия не добавляет видимых действий, контекста или скорости работы, её не стоит делать центральным маркетинговым аргументом.

В iOS 27 Apple уже описывает сценарии, где интерфейс приложения меняется при изменении доступной области. В материалах для разработчиков рекомендуется использовать размерные классы и фактический размер представления, а не принимать решения только по типу устройства или ориентации. В Xcode 27 для проверки таких сценариев доступны изменяемые размеры среды, а в iPhone Mirroring можно наблюдать, как приложение реагирует на изменение окна. Видео Apple о модернизации UIKit-приложения и заметки о поведении iOS 27 дают здесь достаточную основу для предварительной проверки.

Практический вывод: до появления складного устройства вы можете проверить не «режим сгиба», а способность интерфейса использовать разную ширину. Это честнее технически и не требует выдумывать будущий внешний вид системы.

Что должно быть в широком кандидатном кадре

Подготовьте два варианта одного ключевого сценария:

• узкий вариант с компактной навигацией;
• широкий вариант с дополнительной панелью, колонкой или контекстными действиями.

Оба изображения должны быть сняты с реального состояния приложения или поддерживаемого симулятора. Не добавляйте незаявленную системную рамку, вымышленный шарнир, несуществующую строку состояния или логотип устройства. На этапе подготовки достаточно сохранить исходный экран, слой текста и область, которую можно заменить после появления официального макета.

Почему автоматизацию скриншотов нужно менять раньше самих изображений

Главный скрытый риск находится не в дизайне, а в конвейере. Если ваш скрипт одновременно запускает приложение, выбирает устройство, делает снимок, добавляет рамку, размещает заголовок и экспортирует файл, любое новое требование превращается в ручную переделку.

Проверьте четыре типа жёстких зависимостей:

1. Название устройства. Оно может быть зашито в имя файла, шаблон или условие скрипта.
2. Размер холста. Пиксели могут использоваться не только при экспорте, но и при расчёте положения текста.
3. Ориентация. Портрет и альбом могут быть разведены по разным веткам с неполными настройками.
4. Положение текста. Заголовок может быть привязан к абсолютной координате, а не к безопасной области.

Разделите процесс на пять заменяемых этапов:

1. запуск сборки и выбор локализации;
2. переход к нужному сценарию;
3. получение исходного снимка;
4. добавление текста и декоративного оформления;
5. проверка размера, формата и экспорт.

Так вы сможете заменить только источник кадра или финальный шаблон. Не придётся заново описывать сценарии навигации и переводить все тестовые данные.

Пошаговая подготовка конвейера

1. Составьте реестр кадров. Для каждого изображения запишите функцию, маршрут в приложении, локализацию, ориентацию и главный текст.
2. Уберите размеры из логики сценария. Скрипт должен понимать семантическое имя кадра, например dashboard-wide, а не считать любой файл с определённой шириной «правильным».
3. Сохраните исходники без рамок. Экран приложения должен существовать отдельно от маркетингового оформления.
4. Добавьте переменную холста. Она должна задаваться на этапе экспорта после выбора официального размера.
5. Проверьте безопасное кадрирование. Заголовок, кнопки и ключевые элементы не должны исчезать при смене пропорций.
6. Вынесите локализацию в отдельный слой. Перевод текста не должен требовать повторного запуска всего сценария, если интерфейс приложения не изменился.
7. Сделайте контрольный отчёт. Для каждого файла фиксируйте исходник, локаль, разрешение, формат, дату и результат проверки.
8. Запустите пробную сборку в Xcode 27. Используйте текущие доступные инструменты для изменения размеров, но не называйте полученный холст будущим размером складного iPhone.

Apple описывает захват скриншотов в Device Hub с симулятора или физического устройства. Это позволяет отделить проверку пользовательского интерфейса от финального требования App Store Connect. Документация Apple по захвату скриншотов и видео подтверждает, что снимки можно готовить для проверки переводов, разных размеров и обновления страницы приложения до окончательной загрузки.

Как многоязычные страницы увеличивают объём переделки

Один экран редко существует в единственном файле. При добавлении локализаций растёт не только количество изображений, но и число мест, где может сломаться композиция:

• длинный перевод меняет ширину заголовка;
• арабский или иврит требуют проверки направления письма;
• немецкий и французский текст может занять больше места;
• разные пользовательские страницы продукта используют разные первые кадры;
• изменение одного базового экрана затрагивает несколько наборов.

App Store Connect поддерживает до десяти скриншотов и до трёх App Preview для каждой поддерживаемой комбинации устройства и языка. Описание возможностей App Store Connect подтверждает этот предел. Поэтому не стоит заранее умножать неподтверждённый сценарий на все языки и варианты продукта.

Для небольшой команды разумнее сначала зафиксировать структуру каждого кадра:

• какой вопрос пользователя закрывает изображение;
• какая функция находится в фокусе;
• какой текст можно заменить;
• какая часть интерфейса должна остаться неизменной;
• какие элементы допускают широкую компоновку.

Кому нужна шаблонизация уже сейчас

Она оправдана, если вы:

• выпускаете несколько обновлений за сезон;
• поддерживаете много языков;
• используете пользовательские страницы продукта;
• регулярно меняете первые маркетинговые кадры;
• уже применяете автоматические сборки и тесты.

Можно ждать официальных требований, если приложение имеет одну локализацию, небольшой набор статичных скриншотов и редкие обновления. В таком случае ранняя разработка сложной системы может стоить дороже, чем одно аккуратное обновление после публикации Apple.

Как развести релиз приложения и обновление материалов

После одобрения приложения Apple требует создать новую версию, чтобы обновить скриншоты. Это означает, что изменение материалов нельзя планировать как полностью независимую операцию после утверждения текущей версии. Инструкция Apple по загрузке материалов прямо указывает: после одобрения для обновления скриншотов нужно создать новую версию.

Поэтому календарь следует разделить на отдельные узлы:

1. проверка приложения на iOS 27;
2. подтверждение доступности нужного SDK и версии Xcode;
3. проверка интерфейса при разных размерах;
4. захват исходных кадров;
5. дизайн и локализация;
6. финальный экспорт по официальным размерам;
7. загрузка в App Store Connect;
8. отправка версии на проверку.

Не связывайте все эти пункты с предполагаемой датой презентации. Если Apple покажет устройство 9 сентября, это будет только сигналом начать проверку документации. Сроки загрузки могут зависеть от появления нового слота, доступности SDK, готовности команды и статуса версии в App Store Connect.

Перед выбором удалённой среды полезно заранее сопоставить требования проекта: версия macOS, доступ к Xcode, симуляторы, автоматический захват и совместная передача файлов. Общий рабочий контекст и актуальные возможности удалённой разработки можно сверить на странице MacHTML для разработчиков, а технические требования зафиксировать во внутреннем чек-листе команды.

Три выхода для планирования

Продолжать текущий набор. Выбирайте этот вариант, если текущий релиз уже близок к отправке и скриншоты соответствуют опубликованным требованиям.

Подготовить кандидатные кадры. Подходит для карт, редакторов, панелей и других приложений, где широкая компоновка действительно раскрывает функцию.

Пересобрать после официальных данных. Это обязательный путь, если Apple добавит отдельную категорию, изменит допустимые размеры, потребует иной ориентации или введёт специальные правила для складного устройства.

Нужно ли загружать отдельные кадры для сложенного и разложенного состояния

Пока такого требования нет. App Store Connect работает с наборами скриншотов для опубликованных категорий устройств и размеров, а Apple ещё не объявила отдельные слоты для сложенного и разложенного состояния предполагаемого iPhone Ultra.

Не следует автоматически переносить на Apple правила или практики других производителей складных смартфонов. Даже если приложение технически имеет два режима, магазин может принять один набор, использовать масштабирование или определить собственную схему отображения. Это станет фактом только после обновления официальной справки.

До этого разделите две задачи:

• в приложении: проверить, что состояние интерфейса не теряется при изменении доступной ширины;
• в магазине: подготовить только те изображения, которые соответствуют опубликованным слотам.

Для продуктовой команды это снижает риск лишнего обещания. Если на скриншоте показан «развёрнутый режим», а после установки приложение не может воспроизвести такой сценарий, пользователь увидит несоответствие между рекламой и продуктом.

Как готовиться без настоящего складного устройства

Без физического устройства вы не сможете подтвердить шарнир, вырез, тактильные особенности, реальные переходы между состояниями или итоговую системную компоновку. Но вы можете подготовить большую часть публикационного процесса.

Выполните следующий список:

• [ ] Проверьте текущие категории и размеры в справке App Store Connect перед началом экспорта.
• [ ] Составьте список скриншотов, где широкая область даёт реальную функциональную пользу.
• [ ] Запустите эти сценарии в доступном симуляторе или изменяемом окне Xcode 27.
• [ ] Проверьте читаемость текста, навигацию и доступность основных действий.
• [ ] Сохраните исходные снимки отдельно от рамок и рекламного текста.
• [ ] Уберите из шаблонов жёстко заданные названия устройств и размеры.
• [ ] Проверьте все локализации на длину заголовков и направление письма.
• [ ] Подготовьте альтернативный слой текста для широкого кадра.
• [ ] Не добавляйте несуществующую рамку, шарнир или системную панель.
• [ ] Назначьте ответственного за проверку страницы Apple после официального объявления.
• [ ] После обновления документации сопоставьте каждый кадр с новым слотом.
• [ ] Только затем экспортируйте финальные файлы и загружайте их в App Store Connect.

Если удалённая команда не располагает подходящей средой для проверки iOS 27 и автоматической генерации кадров, сначала оцените технические требования к удалённой консоли Mac для разработки. Важно заранее описать требования к macOS, Xcode, симуляторам и совместной передаче файлов, чтобы не смешивать выбор среды с неподтверждёнными параметрами будущего устройства.

Приёмка после объявления устройства

После официальной презентации не начинайте с переделки всех файлов. Сначала зафиксируйте изменения в документах:

• официальное название устройства;
• наличие отдельного типа скриншотов;
• допустимые разрешения;
• портретная и альбомная ориентации;
• правила масштабирования;
• количество файлов в наборе;
• требования к реальному интерфейсу;
• условия обновления уже одобренной версии;
• совместимость новой версии Xcode и SDK;
• ограничения для пользовательских страниц продукта.

Затем проведите приёмку по слоям.

Слой 1 — источник. Кадр получен из реального приложения, а не из макета или рекламной реконструкции.

Слой 2 — компоновка. В сложенном и широком состоянии элементы не перекрываются, текст не обрезается, а ключевое действие доступно.

Слой 3 — маркетинг. Первый экран объясняет пользу широкой области, а не просто показывает необычный корпус.

Слой 4 — локализация. Все языковые версии сохраняют иерархию, смысл и безопасные поля.

Слой 5 — публикация. Файл соответствует актуальному слоту, формату и разрешению App Store Connect.

Если Apple не добавит отдельный слот, не создавайте независимую «складную» серию ради самого факта появления нового устройства. Сначала улучшите изображения с максимальным разрешением, которые уже используются для масштабирования. Отдельный набор оправдан только тогда, когда он нужен по правилам магазина или показывает подтверждённую функцию приложения.

Сейчас у вас есть две плохие альтернативы: ждать до последнего и вручную пересобирать десятки языковых вариантов либо заранее изготовить изображения по слухам, которые могут не совпасть с реальными требованиями. Более устойчивый путь — сохранить текущие материалы, подготовить широкие сценарии и разделить сборку, оформление и экспорт. Для временной проверки iOS 27, автоматизированного захвата кадров и удалённой работы MacHTML может быть удобнее собственного компьютера: вы не привязываете подготовку к покупке отдельного Mac, но и не выдаёте аренду за замену постоянной рабочей станции. Перед публикацией сохраните эту приёмочную ведомость и повторите проверку после обновления официальных страниц Apple.