Как создать приложение для iOS (iPhone): гайд

С iOS у российского бизнеса в 2026 году отношения сложные. Технически собрать приложение под iPhone не труднее, чем под Android, — те же этапы, та же команда. А вот всё, что вокруг кода, — оплата аккаунта разработчика, монетизация, публикация, — превратилось в квест с обходными путями, про который большинство гайдов до сих пор пишут так, будто на дворе 2021 год: подробно объясняют, как зарегистрировать Apple ID, и обходят молчанием тот факт, что оплатить его теперь нечем. Заодно почти никто не упоминает Privacy Manifest, на котором сборка отлетает ещё до ревью, и честно не объясняет, что такое RuStore на iPhone (спойлер: полноценного RuStore там нет, а есть две разные штуки, которые все путают).

Code Pilots делает мобильные приложения с 2014 года — среди проектов VK Fest, приложения для музея Эрарта, платформа GigAnt, PetShop с рейтингом 4.8★. Работаем и с нативкой на Swift, и с Flutter, поэтому про выбор технологии говорим без религиозных войн. Этот материал — про специфику именно iOS: что отличает платформу при разработке и публикации, какой стек брать в 2026-м, нужен ли Mac, на чём валятся релизы и как вообще монетизироваться из России. Общие вещи — нужно ли вашему бизнесу приложение, как устроены этапы, сколько это стоит — вынесены в зонтичный гайд «Как создать мобильное приложение» и в статью о стоимости.

Первый вопрос, который задаёт бизнес: «А много ли в России вообще пользователей iPhone?» Ответ зависит от того, что именно считать, и это редко объясняют. Возьмёте одну метрику — получите 4%, возьмёте другую — «каждый четвёртый». Спорить тут не о чем: правы оба, просто меряют разное.

Разница между iOS и Android не в том, что «у Apple иконки красивее». Она в трёх вещах, которые напрямую бьют по срокам, бюджету и нервам, и о которых знают не все.

Закрытая экосистема — это и проще, и строже одновременно. Apple сама делает и железо, и систему, поэтому устройств мало и они предсказуемы: не нужно тестировать на сотне моделей с разными экранами и прошивками, как на Android. Обратная сторона — Apple диктует правила, и спорить с ними бесполезно. Гайдлайны по интерфейсу (Human Interface Guidelines), требования к приватности, формат публикации — всё это не рекомендации, а условия допуска.

Ручная модерация — обязательный этап релиза, а не формальность. Каждое приложение и каждое обновление проходит через App Review: живой человек (и автоматика) проверяет не только то, что приложение не падает, но и то, что оно делает, как обращается с данными и не дублирует ли десяток таких же. Это закладывают в график: модерация занимает от нескольких часов до нескольких дней, а реджект отбрасывает релиз назад. На Android барьер ниже — там это скорее автоматическая проверка.

Mac в производственной цепочке. Собрать iOS-приложение можно только в среде Apple. Это входной билет, который для команды «с нуля» оказывается неожиданным барьером, — хотя обойти необходимость покупать «мак» сегодня можно, и об этом отдельно.

Эти три отличия и формируют всю специфику iOS-разработки. Дальше — по порядку, начиная со стека.

Мы по умолчанию предлагаем Flutter — и сейчас объясним, где это правильно, а где честнее взять нативку. Подавать кроссплатформу как «всегда лучше» было бы тем самым снобизмом наоборот, которого мы избегаем.

Где выигрывает Flutter. Одна кодовая база собирается и под iOS, и под Android — это одна команда вместо двух, меньше бюджета и быстрее выход на обе платформы сразу. Для каталогов, сервисов, маркетплейсов, личных кабинетов, доставки — то есть для абсолютного большинства бизнес-приложений — Flutter закрывает задачу без видимой пользователю разницы. Собственный движок рендеринга даёт картинку и отзывчивость, неотличимые от нативных. Кейсы вроде VK Fest показывают, что и высокие нагрузки на старте кроссплатформа держит.

Где честно нужна нативка. Тяжёлый AR и компьютерное зрение, низколатентная работа со звуком, глубокая интеграция с системными виджетами и Live Activities, экзотические Apple-API в день их выхода, выжимание максимума производительности из железа — здесь нативный Swift оправдан, и мы скажем об этом прямо.

Гибрид. Часто оптимум посередине: ядро на Flutter, а отдельные тяжёлые или системные части — нативными модулями. Это не компромисс от бедности, а инженерное решение под конкретный продукт.

Развилку видно ещё на этапе аналитики: если в требованиях нет тяжёлого AR, специфичного железа и экзотики — Flutter почти наверняка выгоднее, и переписывать на нативку потом не придётся. Технология служит продукту, а не наоборот.

Короткий ответ: для полноценной разработки и отладки в Xcode — да, среда работает только на macOS. Но владеть «маком» физически уже не обязательно, и это редко кто объясняет.

Собрать и опубликовать iOS-приложение можно через облачную сборку: сервисы вроде Codemagic или GitHub Actions с macOS-раннерами предоставляют виртуальный Mac в облаке, который компилирует, подписывает и заливает сборку. Платный аккаунт Apple Developer для сертификатов и provisioning-профилей всё равно нужен, а вот покупать дорогое железо — нет, особенно если сборки эпизодические. Для Flutter-проектов это особенно органично: основную разработку ведут где угодно, а под iOS собирают на облачном Mac. Так что «нужен дорогой Mac» — устаревший барьер; нужен доступ к macOS-окружению, а это покупается по подписке.

Общая методология этапов — от идеи и ТЗ до тестирования и релиза — одинакова для любой платформы и подробно разобрана в зонтичном гайде. У iOS на каждом этапе свои акценты.

На проектировании дизайн делают под Human Interface Guidelines — свод правил Apple о навигации, типографике, тёмной теме и поведении элементов. Интерфейс, нарисованный без оглядки на HIG, не только рискует на ревью, но и ощущается пользователем как «неродной».

На разработке подключают системные интеграции: пуши через APNs, оплату, карты, нужные фреймворки.

На тестировании к обычным проверкам добавляются прогон на реальных устройствах (симулятор не воспроизводит камеру, биометрию и поведение под нагрузкой точно) и проверка доступности через VoiceOver — экранный диктор, без поддержки которого приложение теряет часть аудитории и баллы в глазах Apple.

Главные iOS-специфичные сложности ждут не в разработке, а на двух следующих рубежах: приватность и публикация.

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

App Tracking Transparency (ATT). С iOS 14.5 приложение обязано через системный запрос спросить у пользователя разрешение на отслеживание между приложениями. Без согласия нет доступа к рекламному идентификатору IDFA — а значит, рушится привычная аналитика и таргетинг. Это закладывают в продуктовую логику заранее.

Privacy Nutrition Labels. В карточке приложения в App Store нужно честно задекларировать, какие данные оно собирает и зачем, — своего рода «состав продукта» по аналогии с этикеткой на еде.

Privacy Manifest — то, на чём спотыкаются. С 1 мая 2024 года приложение и все его сторонние библиотеки, использующие так называемые required reason API, обязаны иметь файл PrivacyInfo.xcprivacy с декларацией, какие данные и API задействованы и на каком основании. Без него App Store Connect отклоняет загрузку сборки ошибкой ITMS-91053 — то есть приложение даже не доходит до ревью, его отбивает на этапе заливки. Коварство в том, что манифест должны иметь не только вы, но и каждая подключённая чужая библиотека; устаревший SDK аналитики или рекламы способен заблокировать релиз всего продукта. Это первое, что мы проверяем перед сабмитом.

Три инструмента, которые путают, хотя у каждого своя роль.

TestFlight — официальный сервис Apple для бета-тестирования. Узкому кругу внутренних тестировщиков сборка раздаётся сразу, а внешним (до 10 000 человек по почте или публичной ссылке) — после лёгкой проверки. Поймать критичный баг на бете несравнимо дешевле, чем ловить его в однозвёздочных отзывах после релиза.

App Store Connect — кабинет, где живёт карточка приложения: название, описание, скриншоты, иконка 1024×1024, ASO-ключевые слова, те самые Privacy Nutrition Labels, и откуда приложение отправляют на ревью.

Transporter — отдельное приложение Apple для macOS, которым заливают готовую сборку (.ipa) в App Store Connect. Удобно, когда подрядчик отдаёт готовый файл, а публикует его уже другой человек. Альтернатива — залить прямо из Xcode (Archive → Distribute).

«Модерация строгая» — бесполезная формулировка. Полезно знать, на чём спотыкаются конкретно. По отраслевым обзорам (не по официальной статистике Apple, которую она не публикует) две причины собирают львиную долю реджектов.

Guideline 4.3 «Spam / дубликат» — около четверти отказов. Приложение похоже на десятки таких же, не несёт уникальной ценности, дублирует функциональность другого вашего же приложения. Под это особенно часто попадают шаблонные продукты в перегретых категориях (гороскопы, гадалки, очередной конвертер).

Guideline 2.1 «краши и баги» — примерно пятая часть. Приложение падает на проверке, часть функций не работает, демо-данные пустые, в форме нельзя пройти регистрацию, потому что у ревьюера нет тестового доступа.

Дальше по списку — нерабочие фичи, нарушения по платежам и подпискам (попытка обойти Apple-биллинг там, где он обязателен), непрозрачность с данными, а ещё отдельный капкан: если приложение требует фирменного устройства (IoT, умный дом), Apple попросит прислать это устройство ревьюеру — иначе гарантированный отказ. Лучшая страховка от всего этого — чек-лист перед Submit for Review: рабочие демо-доступы, заполненный Privacy Manifest, проверенные платёжные сценарии, понятная уникальная ценность.

Самый изменившийся и самый замалчиваемый блок. Стоимость самой разработки считается индивидуально по проекту (об этом — в статье о стоимости), а вот обязательные внешние платежи и сама возможность принимать деньги — отдельная головная боль, которую решают заранее.

Аккаунт Apple Developer — 99 $ в год. Это фиксированный сбор Apple, и сумма не проблема. Проблема в том, что оплатить его российской картой нельзя: карты банков РФ платёжный шлюз Apple отклоняет. На практике платят иностранной картой, через посредников или с аккаунта на зарубежное лицо.

Пополнение Apple ID с телефона закрыли. С 1 апреля 2026 года операторы «большой четвёрки» по указанию Минцифры отключили оплату Apple ID со счёта мобильного — последняя удобная лазейка исчезла. Рабочий обходной путь для пополнения баланса — подарочные карты App Store (16-значный код) с маркетплейсов.

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

RuStore на iPhone — и почему все путают две разные вещи. Полноценного RuStore как магазина на iPhone нет: Apple не пускает сторонние сторы на iOS. То, что есть, — это два совершенно разных продукта, которые в рунете постоянно смешивают:

• RuStore Bridge (тестовый режим с конца 2025 года) — способ установить отдельное iOS-приложение на iPhone через Android-смартфон по кабелю. Нужен модифицированный клиент на Android, авторизация по SMS, временный Apple ID от разработчика, а каталог на старте — буквально единицы приложений, каждое из которых разработчик адаптирует вручную. Это не магазин и не замена App Store, а нишевый обходной механизм.
• RuStore Pay SDK (анонс в декабре 2025-го) — это вообще не про установку, а про оплату. Платёжный шлюз на базе VK Pay, который позволяет принимать платежи внутри приложений, скачанных из App Store, локальными способами и без всякого RuStore. Запуск функции для App-Store-приложений был заявлен на начало 2026 года.

Путать их не стоит: Bridge — про то, как поставить приложение в обход App Store, Pay SDK — про то, как принять деньги внутри обычного App-Store-приложения. Для iOS-аудитории в России основным каналом остаётся App Store, со всеми оговорками про юрлицо выше.

Маршрут iOS-проекта складывается из понятных шагов:

• Определить, нужна ли нативка или хватит Flutter
• Решить вопрос с macOS-окружением (своё или облако)
• Спроектировать интерфейс под HIG
• Заложить приватность (ATT, Nutrition Labels, Privacy Manifest) и платёжный контур с самого начала
• Пройти TestFlight и App Review по чек-листу
• Заранее разобраться с оплатой аккаунта и схемой монетизации из России

Самое дорогое в iOS-проекте — не код, а ошибки на стыках: выбрали нативку там, где хватало Flutter, и переплатили; забыли Privacy Manifest и потеряли неделю на загрузке; не подумали о юрлице и уперлись в монетизацию перед релизом. Code Pilots проводит проект через все эти рубежи целиком — расскажите о задаче, подскажем, где хватит Flutter, а где нужна нативка, и доведём приложение до релиза в App Store.