Разработка iOS-приложения: этапы и что внутри каждого

Этапы разработки iOS-приложения у студий выглядят одинаково: аналитика, дизайн, разработка, тестирование, релиз. Пять слов, за которыми не видно, где проект буксует. Ниже — что происходит внутри каждого этапа и коротко, как настраивается каждая вещь. Это сжатая версия базы знаний, которую я веду с первого своего приложения. Скриншоты Xcode и App Store Connect — из наших проектов, например Meerno, схемы собраны по той же базе. По этому же списку можно проверить любого подрядчика.

Про бизнес-сторону — утилита у вас или продукт и как это влияет на бюджет — отдельная статья.

Короткий ответ

Разработка iOS-приложения состоит из семи этапов: продукт до кода, настройка проекта, интерфейс, сервер и безопасность, системная обвязка (подписки, пуши, фоновые задачи), подготовка в App Store Connect и релиз через ревью Apple. Дольше всего обычно идёт интерфейс и сервер. Чаще всего проект ломается на последних двух: аккаунте разработчика и ревью.

Этап 1. Продукт до кода

Три вещи, без которых писать код рано: проверенная гипотеза, дизайн и название.

Гипотеза. Проверка стоит дешевле любой строчки кода. Что мы делаем по порядку:

1. Читаем отзывы к конкурентам в App Store и обсуждения на форумах: на что жалуются, чего не хватает.
2. Проводим 8–12 интервью с людьми из аудитории. Спрашиваем не «стали бы вы пользоваться», а «как вы решали это в последний раз».
3. Собираем кликабельный прототип в Figma: онбординг и одна-две главные функции. Даём пройти пятерым. Этого хватает, чтобы найти большинство проблем интерфейса.
4. Если продукт будет жить на рекламе, снимаем из макетов 2–3 тестовых креатива и смотрим на клики.

Дизайн. Сначала набросок экранов и связей между ними: что на экране, что может сделать человек, какие нужны данные. По нему дизайнер делает макет в Figma. В макете должны быть все экраны, включая ошибки и пустые состояния, состояния кнопок (нажата, загрузка, ошибка), цвета, шрифты и отступы. Дизайн для iOS опирается на Human Interface Guidelines Apple. Системные компоненты дешевле и сразу выглядят «как iOS». Свой стиль дороже, зато узнаваем.

Название и иконка. Название кажется мелочью, пока не узнаёшь правило App Store: название и подзаголовок меняются только вместе с новой версией приложения. Поэтому имя проверяют по спросу в сторе до дизайна, а не после релиза. Заодно проверяют, свободны ли домен и ник в соцсетях. Как мы подбираем имя — в статье про ASO. Иконку смотрят в маленьком размере и на тёмной теме: деталь, которая видна в Figma на весь экран, на домашнем экране превращается в пятно.

Этап 2. Настройка проекта

Скучный этап, на котором закладываются проблемы на полгода вперёд. Среда разработки iOS-приложений одна — Xcode на Mac, и большая часть настроек живёт в нём. Что сюда входит:

• Info.plist и настройки проекта. Тексты запросов разрешений (камера, геолокация, уведомления), схемы ссылок, поддерживаемые ориентации. Пустая строка в запросе разрешения — частая причина реджекта.
• Цвета и шрифты. Хранятся в каталоге ассетов, сразу со светлой и тёмной темой. Кастомные шрифты регистрируются в Info.plist.
• Локализация. Строки выносятся в каталог строк с первого дня, даже если язык пока один.
• Зависимости через Swift Package Manager. CocoaPods ещё живы в старых проектах, и их конфликты при обновлении Xcode съедают дни.
• Пароли и автозаполнение. Связка с доменом, чтобы iOS предлагала сохранённый пароль.
• Командная работа. Git с нормальным .gitignore, SwiftFormat, чтобы код выглядел одинаково у всех, и доступ нового разработчика к команде в Apple Developer.

Отдельная строка — Build: схемы Debug и Release, разные адреса сервера для теста и прода, номера версий и сборок. Перепутанный адрес сервера в релизной сборке — классика первого запуска.

Как настроить, коротко

Новый проект. File → New → Project → App. Пять решений, которые лучше принять сразу:

• SwiftUI или UIKit. Если код пишется вместе с ИИ, SwiftUI обычно удобнее;
• минимальная версия iOS;
• нужен ли iPad, Mac, часы;
• Storyboard для SwiftUI не нужен, для UIKit его можно убрать, если экраны собираются кодом;
• физические папки или группы Xcode. Физические папки меньше ломаются, когда в проекте несколько человек или ИИ-агент.

Подпись и возможности. Target → Signing & Capabilities. Здесь выбирается команда разработчика, задаётся Bundle ID и ставится галочка «Automatically manage signing» — Xcode сам создаст профили и сертификаты. Возможности вроде покупок, пушей и входа через Apple добавляются кнопкой «+ Capability».

Локализация. Project → Info → Localizations, кнопка «+» добавляет язык. Строки живут в каталоге строк: File → New → File → String Catalog. Отдать текст переводчику: Product → Export Localizations. Получится папка .xcloc на каждый язык, внутри файл .xliff. Переведённый файл возвращается через Import Localizations.

SwiftFormat. brew install swiftformat, в корень репозитория кладётся файл правил .swiftformat, в Build Phases добавляется скрипт, который запускает форматирование при каждой сборке. Спорить о пробелах в код-ревью больше не придётся.

.gitignore. Минимум для Xcode: DerivedData/, build/, xcuserdata/, *.xcuserstate, .DS_Store, и Pods/, если в проекте CocoaPods. Пользовательские настройки Xcode в репозитории дают конфликты на ровном месте. Ключи и пароли не попадают туда никогда.

Второй разработчик. На аккаунте организации человека просто добавляют в команду в App Store Connect. На личном аккаунте в сертификаты пускают только владельца. Второму разработчику приходится вручную добавлять устройство по UDID, выпускать сертификат по запросу с его Mac и пересылать профиль. Это ещё один довод за аккаунт организации, если в проекте больше одного человека.

Этап 3. Интерфейс

Самый видимый этап и обычно самый долгий. Что в нём собирается:

Блок	Что внутри
Стартовый экран	экран запуска и решение, куда вести: онбординг, вход или главный экран
Навигация	таб-бар, стеки экранов, модальные окна, переходы по ссылкам извне
Базовые элементы	кнопки, поля, списки, скролл, пикеры, календарь
Состояния	загрузка, пусто, ошибка, нет сети — для каждого экрана
Алерты и индикаторы	подтверждения, прогресс, таймеры
Анимации	переходы и отклик на нажатие

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

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

Готовые компоненты экономят дни: календарь, бесконечная карусель, анимированные кнопки уже написаны и лежат в открытом доступе. Мы держим список проверенных библиотек в базе знаний и берём их, только если библиотеку поддерживают и она не тянет за собой десяток зависимостей.

Этап 4. Сервер, авторизация, безопасность

Всё, что связывает приложение с сервером и с данными пользователя.

• Авторизация и сохранение входа. Вход по почте, телефону, через Apple. Если в приложении есть вход через сторонние сервисы, Apple требует предложить и вариант, который не собирает лишних данных (правило 4.8). «Войти через Apple» этому требованию отвечает.
• Токены — только в Keychain. UserDefaults попадает в резервную копию, и в незашифрованной копии на компьютере токен читается как обычный текст. Обновление токена прописывается сразу, иначе пользователя выкидывает из аккаунта, как только токен истечёт.
• Network-слой. Один клиент для всех запросов, обработка ошибок и повторов, таймауты. Каждая ошибка сервера должна превращаться в понятное сообщение, а не в бесконечный спиннер.
• Кеш и офлайн. Локальная база (SwiftData или Core Data), если приложение должно работать без сети. Синхронизация при возврате в сеть — отдельная логика и отдельные деньги.
• Файлы и ссылки. Загрузка, выгрузка, открытие документов из других приложений.
• Удаление аккаунта. Если аккаунт можно создать, его должно быть можно и удалить прямо в приложении. Это требование Apple, без него ревью не пройти.

Свой сервер нужен не всегда. Для приложений среднего размера мы часто берём готовый бэкенд: Firebase для входа, базы и серверных функций, CloudKit для данных пользователя в его iCloud. Ниже схема из нашей базы знаний для приложения с ИИ. Человек начинает пользоваться без регистрации, данные сохраняются в iCloud. Когда он входит через Apple, история не теряется. Запрос к ИИ идёт не напрямую, а через серверную функцию: она проверяет подписку и лимиты, а ключ от OpenAI вообще не попадает в приложение.

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

Сюда же — системные возможности, которые подключаются через права (entitlements) в аккаунте разработчика:

Возможность	Зачем	Где спотыкаются
Network Extension	VPN и фильтры трафика	выпускать VPN может только аккаунт организации (правило 5.4)
Universal Links	ссылка с сайта открывает экран в приложении	файл связи на домене, кеширование на стороне Apple
Pass Type ID	карты в Apple Wallet: лояльность, билеты (наш проект)	отдельный сертификат и подпись каждой карты на сервере

VPN-часть у нас самая глубокая: протоколы, Xray, работа в сетях РФ. Это тема отдельной статьи про свой VPN-сервис.

Разбираю такие настройки на живых проектах в Telegram-канале «ИндиХак легко»: что сломалось, сколько стоило починить.

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

Как настроить вход через Apple

1. Apple Developer → Identifiers → ваш App ID: включить Sign in with Apple.
2. Если вход нужен ещё на сайте или в Android-версии, создать там же Services ID и указать домен и адрес возврата. Для входа только на iPhone он не нужен.
3. Keys → «+»: ключ с галочкой Sign in with Apple. Файл .p8 скачивается один раз, его Key ID записывают сразу.
4. В Firebase или на своём сервере указать Team ID, Key ID, сам ключ и Services ID, если он есть. Ключ понадобится и при удалении аккаунта: Apple требует в этот момент отозвать токены входа через Apple.
5. В Xcode: «+ Capability» → Sign in with Apple.

Подводный камень: имя пользователя Apple отдаёт только при первом входе. Если не сохранить его сразу, второй раз его не получить.

Как настроить вход без регистрации через iCloud

Человек открывает приложение и сразу пользуется, а данные не теряются при переустановке и видны на втором устройстве. Работает, если на телефоне выполнен вход в iCloud.

1. В CloudKit Console создать контейнер iCloud.<ваш bundle id>.
2. В App ID включить iCloud с поддержкой CloudKit и выбрать контейнер.
3. В Xcode: «+ Capability» → iCloud, отметить CloudKit и контейнер.
4. В коде получить идентификатор пользователя iCloud и сохранить в Keychain. На всех устройствах с тем же Apple ID он одинаковый.

Как настроить Universal Links

Полная инструкция Apple — Supporting associated domains. Коротко:

1. В App ID включить Associated Domains.
2. В Xcode: «+ Capability» → Associated Domains, строка applinks:example.com.
3. На сайте по адресу https://example.com/.well-known/apple-app-site-association положить файл с Team ID и Bundle ID приложения.
4. В коде обработать входящую ссылку и открыть нужный экран.

Apple кеширует этот файл у себя, поэтому правка на сайте доходит до телефонов не сразу. Запасной вариант — своя схема вида myapp://. Она проще, но открывает приложение, только если оно установлено, и не ведёт на сайт, если его нет.

Этап 5. Подписки, пуши, фоновые задачи

Без этого слоя приложение не зарабатывает, даже если им пользуются.

Подписки делаются через StoreKit 2. Покупку обязательно проверять на сервере и слушать серверные уведомления App Store: продление, возврат, отмена. Без этого пользователь, вернувший деньги, продолжает пользоваться платным.

Пуши доставляет APNs по ключу из аккаунта разработчика: напрямую со своего сервера или через Firebase, если есть ещё Android-версия. Разрешение спрашивают в момент, когда пользователь понимает, зачем ему уведомления. На первом экране — рано. Иначе нажимают «Запретить», и второго шанса система не даёт.

Как настроить подписки

1. Соглашение. App Store Connect → «Соглашения»: подписать соглашение о платных приложениях (Paid Apps) и заполнить банковские и налоговые данные. Без него продукты не загрузятся даже в тестовой среде.
2. Права. В App ID покупки включены по умолчанию, в Xcode добавить «+ Capability» → In-App Purchase.
3. Продукты. Приложение → «Подписки» → группа подписок → подписка: название, Product ID, срок, цена, описание на каждом языке. Product ID делайте говорящим, вроде app.premium.monthly: поменять его потом нельзя. Первая подписка уходит на проверку только вместе с новой версией приложения.

4. Тест в Xcode. Файл StoreKit Configuration (.storekit) описывает те же подписки локально. Подключается в схеме: Edit Scheme → Run → Options → StoreKit Configuration. Покупки идут без сети и без аккаунта, продление можно ускорить, а отказ в оплате — включить вручную.

5. Тест на телефоне (инструкция Apple). App Store Connect → «Пользователи и доступ» → Sandbox → новый тестировщик. На iPhone войти в Sandbox-аккаунт в настройках (раздел App Store или «Для разработчиков», зависит от версии iOS) и купить из сборки Xcode или TestFlight. Так проверяется вся связка с App Store и сервером.
6. Сервер. В «Пользователи и доступ» → «Интеграция» создать ключ для встроенных покупок: Key ID, Issuer ID и файл .p8. С ним сервер спрашивает у App Store статус подписки. В карточке приложения указать адреса для серверных уведомлений: рабочий и тестовый. Сервер хранит, у кого какая подписка и до какого числа, и обновляет запись на продлении, отмене и возврате.

7. Восстановление покупок. Apple требует способ восстановить купленное. Без кнопки «Восстановить» на экране оплаты ревью часто возвращает сборку.

Что проверить в тестах, кроме покупки: отмену, восстановление, смену Apple ID на телефоне и потерю сети в момент оплаты. При сбое сети человек, который уже заплатил, должен остаться в платном статусе до следующей проверки, а не потерять доступ.

Как настроить пуши

На iPhone пуш всегда доставляет APNs, сервис Apple. Выбирать приходится другое: кто передаёт пуш в APNs. Это может делать ваш сервер напрямую, а может Firebase Cloud Messaging (FCM) от Google. Если у приложения есть Android-версия, обычно берут Firebase: на Android пуши и так идут через FCM, и сервер шлёт на обе платформы одинаковым запросом. Приложению только под iOS со своим сервером Firebase не нужен.

Первые шаги одинаковые для обоих вариантов:

1. Возможности. В Xcode: «+ Capability» → Push Notifications. Если нужны тихие пуши для фонового обновления, ещё Background Modes → Remote notifications.
2. Ключ. Apple Developer → Keys → «+» → Apple Push Notifications service. Скачать .p8, записать Key ID и Team ID. Файл скачивается один раз, повторно Apple его не отдаст. Один такой ключ работает для всех приложений команды.
3. Разрешение. В приложении спросить разрешение в нужный момент и зарегистрироваться в APNs, система вернёт токен устройства.

Если пуши шлёт свой сервер:

4. Токен. Токен устройства из шага 3 отправить на сервер и обновлять при каждом запуске: он меняется после переустановки и восстановления из копии.
5. Отправка. Сервер подписывает запрос ключом .p8 с Key ID и Team ID и шлёт его в APNs. Сборки из Xcode получают пуши через тестовый адрес api.sandbox.push.apple.com, TestFlight и App Store через рабочий api.push.apple.com. Перепутали адрес — APNs ответит ошибкой BadDeviceToken, и пуш не придёт.
6. Проверка. Тестовый пуш на конкретный токен отправляется из Push Notifications Console Apple, без своего сервера.

Если пуши шлёт Firebase:

4. Приложение в Firebase. Firebase Console → добавить iOS-приложение с тем же Bundle ID, скачать GoogleService-Info.plist и положить в проект. SDK подключается через Swift Package Manager (пакет firebase-ios-sdk, библиотека FirebaseMessaging), при запуске вызывается FirebaseApp.configure().
5. Ключ в Firebase. Настройки проекта → вкладка Cloud Messaging → APNs authentication key: загрузить .p8 с Key ID и Team ID. Сертификаты .p12 тоже принимаются, но их приходится перевыпускать каждый год, а ключ бессрочный.
6. Что уходит на сервер. Не токен APNs, а идентификатор Firebase: его выдаёт делегат Messaging. Раньше это был токен регистрации FCM, теперь Firebase помечает его устаревшим и советует Firebase Installation ID (флаг FirebaseMessagingInstallationIdEnabled в Info.plist). Токен APNs Firebase забирает сам, подменяя методы AppDelegate. Если подмену выключили флагом FirebaseAppDelegateProxyEnabled = NO, токен передают руками: Messaging.messaging().apnsToken = deviceToken.
7. Отправка. Сервер шлёт пуши через FCM HTTP v1 API с ключом сервисного аккаунта из настроек проекта (Service accounts). Старый Legacy API с «серверным ключом» Google отключил в 2024 году, а в старых инструкциях он ещё встречается.
8. Проверка. Firebase Console → Messaging → новое уведомление → «Отправить тестовое сообщение» на конкретное устройство.

И последнее для обоих вариантов: в профиле дать человеку управлять частотой и тихими часами, например без пушей с 22:00 до 8:00. Иначе, устав от пушей, он выключает уведомления в настройках iPhone целиком, и вернуть их приложение уже не может.

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

Ещё три пункта, которые всплывают перед релизом:

• ATT, App Tracking Transparency. Если приложение отслеживает пользователя между приложениями для рекламы, нужен системный запрос разрешения.
• Аналитика. События ставятся вместе с экранами, а не после релиза.
• Spotlight. Поиск по содержимому приложения из системного поиска iPhone, полезен для приложений с контентом.

Этап 6. App Store Connect и публикация приложения

Здесь ломаются сроки. Код к этому моменту обычно уже готов.

1. Аккаунт разработчика. Apple Developer Program — 99 долларов в год. Личный оформляется быстро, аккаунт организации требует юрлицо и номер D-U-N-S — это недели. Закладывайте их в план до начала разработки. Если приложение будет продавать подписки, заранее проверьте, что аккаунт может подписать соглашение о платных приложениях: на нашем Meerno российский аккаунт этого не позволил, и его пришлось переносить в другую страну. Коротко про публикацию из России и сроки запуска — в посте канала «ИндиХак легко».
2. Создание приложения. Идентификатор (Bundle ID), сертификаты и профили подписи, карточка в App Store Connect.
3. Данные о приватности и манифест. Анкета о собираемых данных и файл privacy manifest в сборке. Расхождение между анкетой и реальным поведением приложения — причина отказа.
4. Карточка в сторе. Скриншоты, описание, ключевые слова, политика конфиденциальности.
5. TestFlight. Бета на живых людях до публичного релиза.
6. Перенос приложения. Если приложение живёт на аккаунте подрядчика, его можно передать на ваш аккаунт. Лучше с самого начала публиковаться с вашего.

Как создать приложение

1. Apple Developer → Certificates, Identifiers & Profiles → Identifiers → «+» → App IDs → App. Указать Bundle ID (например, com.company.app), описание и нужные возможности.
2. App Store Connect → «Приложения» → «+» → «Новое приложение»: платформа, название, основной язык, тот же Bundle ID и SKU — внутренний артикул, его видите только вы.

Что заполнить в карточке

Поле	Ограничение	Что важно
Название	30 символов	меняется только с новой версией
Подзаголовок	30 символов	коротко, что делает приложение; тоже только с версией
Рекламный текст	170 символов	над описанием, меняется в любой момент без обновления
Ключевые слова	100 байт	через запятую, без названий чужих приложений
Описание	4000 символов	обычный текст, без HTML
Скриншоты	до 10 на размер экрана	JPG или PNG без прозрачности, обязательные размеры — в справке App Store Connect
Ссылка поддержки	обязательна	адрес страницы, где с вами можно связаться; просто почта в это поле не подходит
Авторские права	обязательно	год и владелец, например «2026 ООО „Компания“»

Возрастной рейтинг выставляется анкетой. Приложению, которое открывает любые сайты (браузер, VPN), обычно выходит самый высокий.

Как перенести приложение на другой аккаунт

Пока приложение не вышло в стор, его проще пересоздать: новый App ID и Bundle ID в новом аккаунте, заново подписки, ключи и возможности. Если уже вышло — штатный перенос:

1. Проверить условия: оба аккаунта активны, соглашения приняты, версия не на ревью, у получателя нет покупок с теми же Product ID.
2. Сохранить скриншоты, тексты и отчёты: из старого аккаунта они пропадут.
3. Старый аккаунт: App Store Connect → приложение → «Информация о приложении» → Transfer App, указать почту и Team ID получателя.
4. Новый аккаунт принимает перенос в разделе соглашений, на это есть 60 дней.
5. Рейтинг, отзывы и ссылка в App Store сохраняются. Сертификаты, ключи пушей и входа через Apple выпускаются заново, после чего выходит технический апдейт, чтобы убедиться, что всё подписывается новым аккаунтом.

Само переключение занимает минут пятнадцать. Основное время уходит на ключи и проверочную сборку.

Этап 7. Ревью и релиз

Ревью обычно занимает сутки-двое, но каждый отказ добавляет круг.

Чек-лист перед отправкой

1. Сборка собирается из основной ветки, финальные коммиты сделаны.
2. Номер версии и номер сборки подняты в настройках таргета.
3. В релизной схеме стоит адрес рабочего сервера, а не тестового.
4. Финальная сборка прошла тест на живом телефоне.
5. В App Store Connect заполнены рекламный текст и «Что нового».
6. Product → Archive → Distribute App → App Store Connect. Через несколько минут сборка появляется в карточке.
7. Сборка выбрана в версии, подписки привязаны, если они новые.
8. Отправка на проверку. После одобрения версия выходит сама или по кнопке — как выбрали.

Почему отклоняют

Самые частые причины отказа у нас (полный список правил — App Store Review Guidelines):

• 4.3 — приложение похоже на другие. Классика для VPN, трекеров и калькуляторов;
• 5.4 — VPN не от аккаунта организации или без экрана о данных до первого подключения;
• пустые или общие тексты запросов разрешений;
• нет удаления аккаунта.

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

После релиза работа продолжается: обновления под новые версии iOS, A/B-тесты скриншотов, отзывы. Если приложение не находят в сторе, никакой код его не спасёт.

Как проверить подрядчика по этому списку

Задайте пять вопросов:

1. Где будут храниться токены?
2. С чьего аккаунта публикуем и кто его оформляет?
3. Как проверяются покупки — на сервере или только в приложении?
4. Что увидит пользователь без интернета?
5. Что делаем, если приложение отклонят?

Если на третий и четвёртый вопрос ответ «потом разберёмся», это и есть будущий перерасход.

Ещё один вопрос, который стоит задать: ведёт ли подрядчик учёт часов. Я веду такую таблицу около двух лет: дата, часы, что сделано, план. Как она выглядела на VPN-приложении под заказ — в Telegram-канале.

Мы делаем iOS-приложения от 200 000 ₽ и кроссплатформу от 300 000 ₽, со спекой и фиксированной ценой до старта — страница разработки. Если хотите сами пройти путь с нуля, начните со статьи про изучение Swift. Вопросы по проекту — в Telegram.