Apple сообщила, что через две недели после старта продаж iPhone Duo в App Store уже более 100 000 приложений, оптимизированных под складной форм-фактор, и тысячи добавляются ежедневно. Для нас, технарей, это не просто маркетинговый заголовок — это сигнал о том, как Apple выстраивает работу с разработчиками, и хороший повод посмотреть на собственную экосистему Android трезвым взглядом.
Что именно стоит за цифрой 100 000
Формально речь идёт о приложениях, которые получили бейдж «Made for iPhone Duo» — то есть адаптированы под внутренний и внешний дисплеи. Это не «пересборка с новым SDK и всё», а работа с адаптивной вёрсткой: перестроение layout при разворании, корректное поведение при переключении между экранами, обработка изменения плотности пикселей и пропорций. Список уже оптимизированных включает Microsoft Word, Outlook, Zoom, Etsy, Halide Mark III — то есть не только «витринные» демо, но и повседневный рабочий софт. Отдельно отмечается, что приложения, успевшие к запуску, уже получают вторые итерации с улучшенной оптимизацией под оба дисплея — типичная картина, когда первая волна портирования закрывает базовые сценарии, а вторая — полирует детали.
Почему это удалось так быстро
Ключевой фактор — инфраструктура, а не магия. Apple провела более 50 офлайн-воркшопов в 19 городах, которые посетили свыше 2 000 разработчиков. Это дорого, медленно и плохо масштабируется — и именно поэтому работает: разработчик вживую видит, как ведёт себя его layout при развороте, где ломается состояние Activity-подобных экранов, как выглядит контент на внешнем дисплее. Плюс кураторские подборки в App Store и бейдж на странице продукта — прямая мотивация: оптимизированное приложение заметнее в выдаче.
Что это значит для Android
Android-производители и Google работают с фолдаблами дольше, но fragmentation форм-факторов остаётся проблемой: соотношения сторон, размеры внешних экранов, петли, стилусы — у каждого вендора своя геометрия. В результате разработчик вынужден тестировать матрицу конфигураций, а не одну целевую. Отсюда и типичная картина: приложение вроде бы работает, но на развёрнутом экране получаем растянутый список с огромными полями, а состояние сбрасывается при складывании.
Практические выводы, которые можно применить уже сейчас:
-
Проверяйте поведение состояния при смене конфигурации. На фолдаблах смена размера окна — это не редкий edge case, а штатный сценарий.
ViewModel+rememberSaveableи явная обработкаConfigurationизменений должны быть в чек-листе релиза, а не в бэклоге. -
Тестируйте на реальных размерах, а не только в эмуляторе. Эмулятор не покажет, как выглядит контент на узком внешнем экране при ярком солнце и как ведёт себя компоновка при быстром складывании.
-
Используйте адаптивные layout-примитивы платформы.
WindowSizeClass,SlidingPaneLayout,ListDetail-паттерны — они существуют именно для этого, но многие команды продолжают верстать под фиксированный портретный экран. -
Думайте о внешнем дисплее как об отдельном сценарии. Быстрые действия, компактные виджеты, минимум ввода — то, что Apple продвигает через оптимизацию под оба экрана.
Итог
100 000 приложений за две недели — это в первую очередь результат целенаправленной работы с сообществом разработчиков: живые воркшопы, понятные гайдлайны и видимая выгода в сторе. Android-экосистеме не хватает не инструментов — их достаточно — а консистентности требований и предсказуемости форм-факторов. Пока каждый вендор играет по своим правилам геометрии, разработчик будет оптимизировать под «средний» фолдабл, и пользователь это почувствует. Единственный способ сократить разрыв — относиться к адаптивной вёрстке как к обязательному требованию релиза, а не как к приятному бонусу.
