С чего начать разработку IOS-приложения? Как продвигать приложение? На эти и многие другие вопросы ответил IOS-разработчик Том Астахов в нашем интервью. Если в голову закрадывается идея о запуске в приложения в Appstore, то вам придется дочитать этот текст до конца.
Расскажи о себе.
Привет, я Том Астахов, мне 28 лет, и я все еще не умею водить машину. А еще я занимаюсь iOS-разработкой и продуктовым дизайном в агентстве Gold Carrot. Агентство занимается как внешними, так и внутренними (собственными) проектами. В одном из таких — таск-менеджер WEEEK — я полностью беру разработку iOS-приложения: начиная от проектирования с дизайном и заканчивая прототипированием и разработкой.
С чего начать разработку приложения?
Вопрос не однозначный и просто так на него ответа не дать. Как минимум, сначала надо сесть и подумать: «А надо ли оно вообще?» Пропустим вещи, связанные с обсуждениями проекта, процессами и прочей клиентской суетой, и перейдем сразу к сути — к разработке. Имея хорошие макеты (а порой даже и без них), надо определиться с базовыми вещами:
- 1. Определить суть приложения (что оно делает и какие задачи решает) — понимание сути так же должно быть важно разработчикам
- 2. Грамотно разделить на логические части (модули / слои)
- 3. Возможно заранее определиться с архитектурой (MVC, MVVM, VIPER или что-то еще)
- 4. Заложить фундамент: настроить гит, создать репозиторий, выбрать минимальную версию iOS, выбрать свой джедайский путь (проверенный UIKit или новомодный SwiftUI) и создать проект
- 5. И отвалить $99 за годовую подписку в AppStore для разработчика, конечно же
В целом, этого достаточно для проекта любых масштабов. Но чем больше проект и разработчиков в нем, тем больше действий необходимо для обеспечения комфортной и быстрой разработки.
В чем разница между разработкой разных приложений? Есть какие-то свои особенности?
В общей картине разработка разных приложений выглядит одинаково: разработчик (или команда) берет и делает приложение. Все. Вот так просто.
Для разработки большого приложения (например, банковского) нужна большая команда. И с таким подходом будет сложно вместе работать. Поэтому команды придумывают свои процессы, в которых им будет комфортно работать: настраивают гит, занимаются DevOps-овскими штучками, делятся на еще меньшие команды, пишут тесты (зачастую одна команда пишет тесты для всех остальных команд) и естественно начинают делиться опытом.
Разницы в разработке разных приложений много. Примерно как разница между синим цветом и кошкой на слоне — ничего не понятно, но очень много. Вот несколько очевидных различий:
- 1. Сроки и сложность
- 2. Состав команды
- 3. Фреймворки и зависимости в приложении
- 4. Возможность приложения работать в оффлайне
- 5. Зависимость от сервера (бэкенда)
Нет таких двух приложений, которые создавались бы примерно одинаково (за исключением приложений клонов).
Как опубликовать приложение?
Достаточно просто. Надо зарегистрировать аккаунт разработчика на сайте Apple для разработчиков и заплатить $99 за годовую подписку. Это подписка дает возможность в течение 1 года выпускать приложения в AppStore от своего лица.
Также есть командная подписка, она стоит уже 999$ в год.
Но если денег нет, то есть 2 выхода:
- 1. Пиратские сторы (магазины приложений). В двух словах, пользователь скачивает пиратский стор и устанавливает себе сертификат из этого стора. И далее это приложение устанавливает ваше приложение. Этот вариант не особо хорош, потому что пользователю будет угрожать банальный взлом телефона.
- 2. Выложить исходный код приложения, например, на GitHub. Другие разработчики смогут собрать и запустить ваше приложение у себя. А кто-то, может быть, даже задонатит на стаканчик кофе.
Чем отличается публикация в IOS и Android?
На самом деле здесь не так много отличий.
• Программа для разработчиков
И в AppStore, и в Google Play нужно сначала заплатить, чтобы иметь возможность выпускать приложение. Вот только в AppStore это делается каждый год (как подписка), а в Google Play надо заплатить всего один раз.
• Проверка приложений
Разумеется, никто не даст вам выпустить приложение, которое не будет работать или будет иметь вредоносный характер для человека.
AppStore и Google Play в этом похожи. После сборки приложения его билд (файл приложения) проходит ревью: сначала идет проверка билда (его проверяет машина), а затем приложение проверяют сотрудники Apple или Google. Проверка людьми самая страшная проверка, потому что они проверяют приложение на соответствие их гайдлайнам.
- Забыл кнопку Apple для входа в аккаунт? — приложение не пропустят в AppStore, то есть зареджектят (reject)
- Приложение вылетает при запуске? — реджект
- В информации о приложении указал русский язык, а приложение на только английском — тоже реджект
В среднем ревью моих приложений в AppStore проходит за 6-9 часов. От чего зависит этот фактор — известно только сотрудникам Apple. Самое короткое ревью от загрузки файла до выпуска приложения в AppStore у меня было 12 минут, а самое долго — почти 4 дня.
Есть еще один неприятный момент для меня, как для iOS-разработчика, — это то, что ревью в AppStore проходит куда строже, чем в Google Play. Но есть и плюс: Apple всегда укажет подробную причину реджекта и прикрепят вырезку из гайдлайнов со скриншотами проблемных мест в приложении. А в случае чего с ними можно и поспорить, но делать этого я не рекомендую, потому что это может затянуться надолго. Также бессмысленные споры с поддержкой могут быть чреваты блокировкой аккаунта.
Как продвигать приложение?
Это вопрос, ответ на который волнует примерно всех разработчиков.
App Store Optimisation (ASO) — так называют продвижение в AppStore. Есть много мнений, споров и теорий о том, как делать это лучше, но в двух словах все выглядит просто. AppStore смотрит на несколько факторов при показе в поиске:
• Название приложения — 30 символов
• Краткое описание — 30 символов
• Полное описание — 4000 символов
• Превью-картинки и видео приложения (оно заполняется отдельно для каждого размера устройства и языка) — до 10 картинок или видео
• Промо текст
• Ключевые слова (они не видны пользователю) — 100 символов
• Частота обновлений приложения
• Частота обновлений текстов, перечисленных ранее
• Частота обновлений превью-картинок
При поиске в AppStore в первую очередь учитывается название, затем ключевые слова и в последнюю очередь краткое описание. И конечно же, в ASO есть свои лайфхаки. Например, есть неочевидный момент с локализацией. Ключевые слова можно задать для английского в США (U.S. English) и английского в Англии (U.K. English) — и по факту у нас как будто уже 200 символов для ключевых слов на один и тот же язык.
Что важно учитывать при разработке интерфейса для пользователя?
Самое сложное — это понять, как люди пользуются интерфейсами, почему они быстро или медленно привыкают к апдейтам в приложении, как вообще за этим всем уследить.
Это проблема больше касается дизайна. Но, к слову, разработчик по-хорошему должен разбираться в дизайне, а дизайнер в разработке.
В интерфейсе стоит учитывать его (простите за каламбур) считываемость, очевидность и простоту. Чем сложнее интерфейс, тем меньше хочется им пользоваться. Чем запутаннее интерфейс, тем сложнее человеку сделать нужное ему действие.
UX и UI не стоит разделять в интерфейсах — что в приложении, что в вебе. Также важно ориентироваться на гайдлайны, которые предоставляет Apple, — Human Design Guidelines (HDG). HDG — это мастхэв в копилке знаний iOS-разработчика.
Также отдельная тема — это доступность (Accessibility). Это про то, как, например, незрячий человек пользуется смартфоном. Разработчик из Dodo Engineering пишет очень хорошую книгу эту тему. Она так и называется — «Про доступность в iOS».
Как понять, что бизнесу нужно приложение и для каких бизнесов подойдет приложение?
Очень просто. Если приложение решает бизнес-проблему и окупается, то надо. В любом другом случае — это будет тратой времени, денег и нервов.
Если есть какой-то бизнес, и бизнес хочет приложение, потому что «ну это же приложение, люди там будут пользоваться, то-сё», то без других веских поводов это скорее всего будет провал.
Разберем на примере. Допустим, бизнесом является ресторан с суши единственной точкой в городе. В этом случае ресторану не нужно приложение ни для заказа, ни для бронирования, ни для чего-то еще. В этом случае проще и дешевле будет посадить человека, который будет передавать заказы и бронировать столики вместо приложения.
Пример: любая локальная кухня возле вашего дома
Хорошей же причиной для создания приложения будет сеть таких ресторанов в городе или по стране. В этом случае надо заниматься цифровизацией бизнеса и переводить процессы в диджитал. Приложение имеет хорошее свойство — оно умеет работать безотказно и при высоких нагрузках, а «платить» ему надо столько же (то есть только за поддержку приложения). Посадить человека с телефоном для этого уже не получится, так как он один не справится, а садить 200 человек — очень дорогое удовольствие.
Пример: Додо Пицца или Кухня на районе
Как правило, малому бизнесу приложения не нужны, потому что почти всегда проблемы можно решить с помощью уже существующих сервисов. Делать собственное приложение для парикмахерской — самая бесполезная вещь в мире после просмотра покупки pop-it'ов. Онлайн запись можно на сеансы перевести в готовых CRM — например, в YCLIENTS или (о, ужас) Битрикс24. И вести учет расходов с постановкой задач тоже лучше в онлайне — например, в WEEEK, Notion или Airtable.
Как ты понимаешь, что интерфейсы уже готовы для разработки, и проверяешь их перед началом работы?
Готовность интерфейсов — это опять же задача дизайнера, всю логику и взаимодействия продумать должен только он. Он же должен спроектировать интерфейс так, чтобы у разработчика не возникало вопросов по его использованию.
Будем полагать, что эти интерфейсы переданы мне в Figma / Sketch (в других случаях это боль). Чтобы проверить макет, я оцениваю его по пунктам:
- 1. В порядке ли макет? Можно ли на нем чисто визуально отделить экраны приложения от черновиков?
- 2. Все ли в порядке с компонентами, цветами, ассетами?
- 3. Есть ли экраны с микроанимациями и как они работают?
- 4. Как ведет себя контент при скролле?
- 5. Как ведет себя контент, когда открывается клавиатура?
- 6. Все ли места в приложении могут прерваны, и если не могут, то почему?
Чем больше проблем разработчик выявит перед программированием и передаст дизайнеру обратно, тем легче ему будет в разработке.
В этом деле важна коммуникация «дизайнер-разработчик». Контр-мнение разработчика дизайнеру с большей вероятностью улучшит интерфейс, но это не точно, так как многое субъективно. Но факт важности коммуникации отрицать нельзя.
Кстати, ты упомянул, что по совместительству еще и дизайнер. Есть ли плюсы, когда ты дизайнер и разработчик в одном лице?
Да, есть. Как я раньше сказал, между дизайнером и разработчиком важна коммуникация, чтобы понять, что и как правильно делать. В этом плане мне, как дизайнеру, проще продумать интерфейс, зная программные ограничения. И проще как разработчику — потому что макет мне полностью понятен.
Но также это порождает и большущий минус. Сочетая в себе разработчика и дизайнера, я опускаю некоторые интерфейсные моменты в голове и позволяю себе их не отрисовывать. Спустя какое-то время бывает сложно вспомнить, что тут или там должно было быть, и какие-то вещи я не вынес в условные компоненты.
Каково заниматься разработкой без команды?
Скучно и одиноко, но в целом пока что больших трудностей не возникало и все было супер.
С одной стороны, мне никто не скажет, что мой код плох, а я не возражу: «Ну и что? Он же работает!» С другой стороны, мне никто не подскажет, было ли какое-то другое решение у той или иной задачи. Иногда я обращаюсь с вопросами в разные Telegram-чаты по разработке, и это помогает. А иногда и не очень — например, когда задача слишком большая или надо определиться с архитектурой и грамотно все разбить на модули.
Резюмируем.
Спасибо, Том, за интересные ответы! Резюмируем для вас: в этом интервью мы рассказали, с чего начать запуск IOS-приложения, какие особенности есть у приложений, что нужно сделать, чтобы опубликовать их, что нужно учитывать при разработке интерфейса для пользователя и как дизайн связан с программированием.
