Разработка приложения для iOS: что нужно знать заказчику

Разработка приложений для iOS стоит от 350 000 ₽ и занимает 8-16 недель до появления в App Store. Сверху - Apple Developer Program, 99 $ в год, и отдельная неделя, а иногда две, на получение номера D-U-N-S, если аккаунт оформляется на юрлицо, а не на человека.

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

Разработка приложений для iOSот 350 000 ₽сроки: 8-16 недель

Чем разработка приложений для iOS отличается для заказчика

Разница не в языке программирования, а в том, что вы не владеете каналом дистрибуции.

Сайт можно выложить на хостинг в любой момент и переделать через час. Android-приложение в крайнем случае раздаётся файлом. iOS-приложение попадает на телефон пользователя только через App Store, и каждую сборку смотрит живой человек в Apple. Он открывает приложение, кликает по экранам, проверяет соответствие описанию и решает, пускать вас или нет. Это не автоматика, и это не переговоры.

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

Аккаунт, 99 $ и D-U-N-S

Аккаунт бывает индивидуальный и организационный. Индивидуальный оформляется за день, но в сторе рядом с приложением будет стоять имя физлица. Организационный показывает название компании и позволяет заводить несколько разработчиков, но требует номер D-U-N-S от Dun & Bradstreet.

D-U-N-S бесплатный, но выдаётся не мгновенно, и Apple сверяет название компании с реестром побуквенно. Расхождение в организационно-правовой форме или в старом юридическом адресе отправляет заявку на второй круг. Поэтому заявку я прошу подавать в первую неделю проекта, параллельно с аналитикой, а не тогда, когда сборка готова.

Что проверяет ревью App Store

Гайдлайнов много, но по моему опыту 80% отказов приходится на четыре пункта.

4.2 Минимальная функциональность

Самый опасный для гибридного приложения. Apple отклоняет приложения, которые представляют собой сайт в обёртке: если приложение просто открывает веб-страницу и не даёт ничего сверх браузера, его не пустят.

Проблема решается не тем, «на чём написано», а тем, что приложение делает. У Capacitor-приложения интерфейс живёт локально в сборке, а не грузится с сервера, и это уже другая история. Плюс нужны нативные возможности, которых у сайта нет: push, биометрия, работа с камерой и галереей, шеринг, офлайн-доступ к данным. В моём прошлом приложении эту роль закрывали собственные плагины на Swift, включая Share Extension на SwiftUI, через который контент попадал в приложение из любого другого приложения системы. Такое ревью пропускает без вопросов.

Чего делать точно нельзя: выпускать первую версию, где половина экранов открывается в WebView с боевого домена.

5.1.1 Удаление аккаунта

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

3.1.1 Покупки внутри приложения

Цифровой контент, подписки, доступ к платным функциям - только через In-App Purchase с комиссией Apple 30%, либо 15% для участников программы для малого бизнеса с оборотом до 1 млн $ в год. Обойти нельзя, ссылку «оплатить на сайте» тоже нельзя.

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

2.1 Полнота предоставленных материалов

Демо-доступ для проверяющего: логин и пароль в поле App Review Information. Если вход по SMS - постоянный тестовый номер с фиксированным кодом, иначе проверяющий упрётся в экран, куда не придёт код. Сюда же относятся скриншоты, соответствующие реальному приложению, и описание, не обещающее того, чего нет.

Чеклист

Чек-лист по релизу в App Store

Что готовится до старта, что смотрит проверяющий и что живёт после релиза.

20 проверок 9 критично 7 важно 4 можно потом

01 До старта разработки

• критично Apple Developer Program оформлена, 99 $ в год оплачены чинить до запуска
• критично D-U-N-S получен, название совпадает с реестром побуквенно чинить до запуска
• критично Решено, есть ли продажа цифрового контента: от этого зависит IAP и комиссия чинить до запуска
• критично Политика конфиденциальности опубликована по постоянному адресу чинить до запуска
• критично Список нативных возможностей: без них риск отказа по 4.2 чинить до запуска

02 Что проверяет ревью App Store

• критично Приложение не является сайтом в обёртке (гайдлайн 4.2) чинить до запуска
• критично Удаление аккаунта доступно из приложения (5.1.1) чинить до запуска
• критично Цифровые покупки идут через In-App Purchase (3.1.1) чинить до запуска
• критично Демо-доступ и тестовый номер с фиксированным кодом (2.1) чинить до запуска
• важно Sign in with Apple, если есть вход через другие соцсети в первый месяц
• важно App Privacy совпадает с реальным сбором данных в первый месяц

03 Технические требования

• важно Каждое разрешение в Info.plist объяснено человеческим языком в первый месяц
• важно Поддержка двух последних мажорных версий iOS в первый месяц
• важно Экран запуска, иконка, скриншоты под все требуемые размеры в первый месяц
• важно Автоподпись через Fastlane match, сертификаты не на одном ноутбуке в первый месяц
• важно Отдельные окружения dev, stage и prod с разными идентификаторами в первый месяц

04 После релиза

• можно потом Мониторинг падений и разбор крэшей по версиям iOS когда дойдут руки
• можно потом TestFlight для обкатки следующей версии на реальных людях когда дойдут руки
• можно потом Проверка сборки на бете новой iOS каждый сентябрь когда дойдут руки
• можно потом Обновление скриншотов при появлении новых размеров экранов когда дойдут руки

Sign in with Apple и прозрачность отслеживания

Если в приложении есть вход через сторонние сервисы вроде Google или ВКонтакте, Apple требует добавить и Sign in with Apple как равноправный вариант. Если вход только по телефону или почте, требование не действует. Технически это день работы, но её надо заложить: пользователь может скрыть почту, и вы получите адрес-ретранслятор вместо настоящего, что ломает наивную логику «ищем пользователя по email».

App Tracking Transparency касается тех, кто передаёт идентификатор устройства рекламным сетям или связывает поведение пользователя с данными из других приложений. Тогда нужен системный запрос на отслеживание, и большинство людей на него отвечает отказом. Если вы не покупаете рекламу с атрибуцией установок, проще не собирать эти данные вовсе: и запроса не надо, и декларация App Privacy становится честной и короткой.

Info.plist и разрешения

Каждое разрешение сопровождается строкой-объяснением, которую пользователь видит в системном диалоге. Формальные отписки типа «приложению нужен доступ к камере» проверяющие возвращают. Работает конкретика: «камера нужна, чтобы сфотографировать предмет и добавить его в вашу коллекцию».

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

Сроки проверки и что делать при отказе

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

Отказ приходит в Resolution Center с номером гайдлайна и, как правило, скриншотом. Дальше два пути. Если проверяющий не разобрался, пишется ответ прямо в переписке с объяснением и видео сценария - это работает чаще, чем кажется, и занимает сутки. Если нарушение реальное, спорить бессмысленно: правится и загружается новая сборка. Формальная апелляция в App Review Board существует, но она долгая, и я видел её результат ровно в тех случаях, когда правота была очевидной.

Версии, устройства и обкатка

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

TestFlight - способ раздать сборку до релиза: до сотни внутренних тестировщиков без проверки и до 10 000 внешних после лёгкой проверки. Внешняя группа удобна для клиента и его сотрудников: они видят приложение в реальных условиях, и правки приходят до публикации, а не в отзывах.

Что ломается со временем: каждый сентябрь выходит новая iOS, вместе с ней новая Xcode, и Apple объявляет дату, после которой сборки принимаются только с новым SDK. На гибридном проекте это тянет за собой обновление Capacitor и плагинов, и раз в год стабильно находится плагин, который под новую версию не собирается. На прошлом мобильном проекте я закладывал на такое обновление несколько дней ежегодно и держал CI на GitHub Actions с Fastlane и автоподписью через match, чтобы сертификаты не были привязаны к одному ноутбуку, а три окружения с разными идентификаторами и иконками стояли на телефоне одновременно.

Российская специфика

Оплата Apple Developer Program российской картой не проходит, нужен другой способ оплаты. Приложения российских компаний из App Store удаляли и продолжают удалять, и это риск, который надо принимать осознанно. Приём платежей внутри приложения через российский эквайринг работает для физических товаров и услуг, а для цифрового контента упирается в IAP, которая в текущих условиях доступна не всем.

Практический вывод: iOS остаётся обязательной платформой по аудитории, но релиз только на iOS в России я не советую. Android и RuStore дают запасной канал, а один код на Capacitor делает обе платформы за одну разработку.

Что входит в работу, как считается бюджет и какие нативные части пишутся руками, описано на странице разработки iOS-приложений.