От iPhone к iPad: упрощение дизайна и разработки приложений для устройств iOS

От: Свилен Киров

Сегодня мы рассмотрим, как сделать так, чтобы приложение для iPhone достаточно хорошо выглядело на iPad с минимальными усилиями. Это тема, которая актуальна для многих команд, так как дизайн для iPad обычно не является главным приоритетом, но по какой-то причине менеджеры проектов все равно предпочитают его.

Вы ожидаете, что дизайн и разработка идут рука об руку, и для приложений iPhone это обычно происходит. Однако это часто не относится к приложениям для iPad. В таком поведении есть свои достоинства, поскольку тот же код, который выполняется на iPhone, также работает и на iPad. Да, макет может быть немного неправильным, но действительно ли это так важно?

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

Сказав это, вот четыре категории, к которым может относиться ваша команда, когда дело доходит до разработки и поставки для iPad:

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

Все начинается с адаптивного дизайна…

Если у вас уже есть приложение для iPhone, которое хорошо работает на всех экранах iPhone, iPad — это не более чем пара дополнительных размеров экрана, на которые следует обратить внимание.

Давайте посмотрим на iPhone SE и iPhone 14 Pro Max в качестве примера разных размеров экрана. Pro Max почти в 1,5 раза выше и имеет значительно более высокое разрешение, чем SE. Из-за этого он лучше отображает активы более высокого качества и может отображать больше контента на экране. Почему бы не использовать это и предоставить пользователям iOS, которые владеют самыми дорогими устройствами, лучший опыт?

Точно так же, если вы разрабатываете функцию для красивого экрана 14 Pro Max, как заставить ее работать на iPhone SE? Конечно, вы можете сделать каждый экран прокруткой, но это не всегда приводит к лучшему UX. Когда вы добавите в смесь длинные языковые локализации, вы быстро поймете, почему дизайн с фиксированными размерами не работает даже для одного размера экрана.

Начиная с iOS 6 (2012 г.), Apple предоставила нам технологию Auto Layout, которая помогает нам отказаться от контейнеров и элементов фиксированного размера. Это делает адаптивный дизайн намного проще для разработчиков и к настоящему времени должен стать способом работы по умолчанию. Однако, как оказалось, даже дизайнеры и продакт-менеджеры, которые использовали адаптивный дизайн в других контекстах, таких как Интернет, на самом деле не думают о мобильных устройствах как об адаптивной платформе.

Чтобы помочь преодолеть этот разрыв, возможно, стоит обсудить с ними различные размеры экрана, на которых можно использовать ваше приложение (SE, Pro Max, iPad и т. д.). Чтобы лучше убедить заинтересованные стороны, возможно, стоит даже проверить данные о проценте пользователей на каждом устройстве. Firebase собирает эту информацию, или, если у вас есть команда Business Insights, они должны получить ее для вас.

Если ваша команда уже занимается адаптивным дизайном для разных экранов iPhone, поздравляем! Вы очень близки к тому, чтобы иметь достаточно хорошо выглядящее приложение для iPad.

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

Теперь, когда ваше приложение выглядит прилично на iPad, необходимо рассмотреть еще несколько моментов. Из-за большего экрана жесты несколькими пальцами выполнять проще. Это отличная возможность сделать ваше приложение еще более удобным, добавив удобные жесты для опытных пользователей. В дополнение к этому пользователи iPad могут иметь доступ к оборудованию, такому как клавиатура, трекпад или карандаш Apple. Учитывая эти инструменты, стоит подумать о том, как можно улучшить работу вашего приложения, чтобы учесть их.

Делаем вашу жизнь проще:

Последние пару месяцев наша команда работала над тем, чтобы iPad выглядел достаточно хорошо, и в этом разделе я хочу поделиться некоторыми хитростями, которые мы обнаружили в процессе. Это ни в коем случае не лучшие решения, но это некоторые углы, которые, кажется, можно срезать. 😀

• Если вам трудно разрабатывать макеты iPad для всех ваших экранов, вы можете сделать себе одолжение и сделать это только для самых важных. Для остальных вы можете ввести максимальную ширину и/или максимальную высоту содержимого на нем. Таким образом, вы можете сохранить то же соотношение сторон, что и на экране iPhone, таким образом, получая такой же красивый макет iPhone. Конечно, вы не будете использовать доступное дополнительное пространство, но в некоторых случаях это достаточно хорошее решение.
• Заполнение аспекта — ваш друг, когда дело доходит до изменения размеров активов. Убедитесь, что ваши активы достаточно хорошо выглядят на устройствах с самым высоким разрешением — iPhone Pro Max и iPad Pro — а заполнение аспектов позаботится обо всем остальном.
• Держитесь подальше от UIDeviceOrientation, когда речь идет о макете пользовательского интерфейса. Хорошо, что он поддерживает isLandscape и isPortrait, но знаете ли вы, что есть еще isFlat? Да, каждый раз, когда iPad остается на плоской поверхности, его ориентация не является ни альбомной, ни портретной, а это означает, что эти проверки не должны использоваться для макета пользовательского интерфейса. Вместо этого Apple предлагает принимать решения на основе доступного места в текущем окне. (например, иметь один макет, если ширина меньше 300 pt, и отдельный, если больше).
• Аналогично, проверки isiPhone / isiPad ненамного лучше, и их также следует избегать, когда речь идет о макете пользовательского интерфейса. Причина в том, что из-за разделенного экрана iPad окно iPad может иметь соотношение сторон, аналогичное окну iPhone. Поэтому любые предположения, что iPad шире, здесь не сработают. Решение здесь состоит в том, чтобы снова придерживаться размера окна, а не принимать решения на основе текущей платформы.
• Проверка того, что ваши экраны выглядят нормально как в светлом, так и в темном режиме, с длинным и коротким текстом, в разных состояниях экрана для всех интересующих устройств, может оказаться непосильной задачей. Именно здесь тестирование моментальных снимков может быть чрезвычайно полезным при разработке адаптивного дизайна. Его можно использовать для проверки того, что будущие изменения не изменят макет непреднамеренно. Дополнительным преимуществом является то, что если вы хотите убедиться, что конкретный экран хорошо выглядит на всех платформах, вы можете просто просмотреть его снимки или, что еще лучше, засыпать ими вашего дизайнера продукта.
• В зависимости от размера кодовой базы может быть полезно иметь более одной процедуры моментального снимка. Более короткий для запуска в CI, который проверяет, что ключевые экраны в большинстве случаев выглядят хорошо, и что состояние всех экранов по умолчанию не изменилось. Затем более длинный «ночной», который мог бы протестировать все возможные экраны во всех возможных случаях и убедиться, что ни одна ошибка не осталась незамеченной.
• Для больших кодовых баз может иметь смысл создать приложение типа Gallery. Цель такого приложения — иметь каталог всех ваших представлений с фиктивными данными. Это делает итерации пользовательского интерфейса намного быстрее, поскольку вам не нужно запускать и перемещаться по фактическому приложению, что обычно занимает некоторое время.
• Дополнительным преимуществом приложения Галерея является то, что его можно запускать на симуляторе, чего нельзя сказать о всех приложениях, использующих неимитируемые аппаратные функции. Это может быть очень полезно, например, когда речь идет о странных ошибках, связанных с версией iOS. Это может быть очень удобно для менеджеров проектов и дизайнеров, поскольку они могут легко увидеть существующие компоненты в приложении и выбрать лучших кандидатов для будущих макетов.
• Компонуемость SwiftUI великолепна, когда речь идет о повторном использовании компонентов для разных макетов. По нашему опыту, очень просто определить компоненты, которые будут использоваться на данном экране, а затем сделать два независимых макета для более широкого и более узкого экранов соответственно. Поддерживать их также несложно, а полученный код легко понять. Дополнительным преимуществом SwiftUI является то, что вы также можете использовать предварительный просмотр экрана, что также позволяет ускорить разработку пользовательского интерфейса.

Заключение

Как оказалось, дизайн для iPad может быть таким же простым, как создание адаптивного дизайна для iPhone с парой дополнительных шагов. Пока ваша продуктовая команда убеждена, что продукт более высокого качества, связанный с адаптивным дизайном для iPhone, того стоит, не составит большого труда продвинуть его немного дальше, чтобы поддерживать также и iPad.

Однако следует помнить, что дизайн для iPad — это бизнес-решение. Таким образом, вам необходимо оценить, перевешивают ли выгоды затраты. Мы надеемся, что после прочтения этого вы сможете сократить расходы, связанные с более качественной поддержкой iPad, что, в свою очередь, должно сделать его более выгодным вложением.
—
Создавайте волшебство вместе с нами
Мы всегда в поиске многообещающих новых талантов. Если вы заинтересованы в разработке революционных новых инструментов для авторов, мы хотим услышать от вас. От написания кода до исследования новых функций вас будет окружать поддерживающая команда, которая живет и дышит технологиями.
Похоже на вас? Подать заявку здесь.