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

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

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

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

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

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

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

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

Swift, и где ещё прячется Objective-C

Новые iOS-приложения пишут на Swift — официальном языке Apple с 2014 года: быстрый, безопасный, читаемый. Старый Objective-C ещё живёт в больших legacy-проектах, которые начинали десять лет назад, но для нового продукта его не выбирают. Если подрядчик предлагает писать новый проект на Objective-C, это либо очень специфический случай, либо повод насторожиться.

SwiftUI или UIKit: выбор с позицией

Внутри нативной разработки есть две технологии построения интерфейса, и выбор между ними — не дело вкуса.

UIKit — зрелый императивный фреймворк с пятнадцатилетней историей. Максимальный контроль над каждым пикселем, гигантская база готовых решений, поддержка старых версий iOS.

SwiftUI — современный декларативный подход: меньше кода, выше скорость разработки, единый код для iPhone, iPad, Apple Watch и Mac.

Практическая позиция на 2026 год: если минимальная поддерживаемая версия — iOS 17 и выше, для нового проекта берут SwiftUI — он закрывает порядка 80% задач и заметно ускоряет работу. UIKit остаётся там, где нужны сложная кастомная графика, поддержка старых iOS или доступ к зрелым API, которых в SwiftUI пока нет.

На практике крупные приложения часто живут в гибриде: каркас на SwiftUI, отдельные сложные экраны на UIKit через слой совместимости. «Перепишем всё на SwiftUI» ради моды — плохая причина; «возьмём SwiftUI, потому что проект новый и под свежие iOS» — хорошая.

Где хранить данные: SwiftData или Core Data

Для локального хранения данных у Apple теперь два инструмента. SwiftData (с iOS 17) — современный, написан на чистом Swift, бесшовно дружит со SwiftUI; минус — пока поддерживает только простые сценарии миграции и в редких случаях «тихо» не сохраняет данные, если неаккуратно настроить.

Core Data — проверенный временем ветеран: его берут для проектов с поддержкой iOS младше 17, для сложных моделей данных и тяжёлых миграций, для синхронизации через CloudKit и для больших существующих кодовых баз. Выбор простой: новый проект под свежие iOS — SwiftData; всё остальное и сложное — Core Data.

Фреймворки Apple, ради которых и берут нативку

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

• APNs — пуш-уведомления (на iOS они идут через серверы Apple, минуя Google FCM);
• WidgetKit — виджеты на домашнем экране и Live Activities (живые активности на экране блокировки);
• ARKit в связке с RealityKit — дополненная реальность;
• HealthKit — данные здоровья и фитнеса;
• CarPlay — интеграция с автомобилем;
• Sign in with Apple — вход через Apple ID;
• App Intents / Siri — голосовые сценарии и быстрые команды.

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

Мы по умолчанию предлагаем 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 аналитики или рекламы способен заблокировать релиз всего продукта. Это первое, что мы проверяем перед сабмитом.

Требование, симметричное android-овскому, но жёстче. Apple обязывает собирать приложение свежим инструментарием: с 28 апреля 2026 года любая сборка, отправленная в App Store, включая обновления работающих приложений, должна быть собрана с SDK iOS 26 или новее.

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

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

Раздел, который в 2026 году перестал быть формальностью. Apple расширила градацию возрастных рейтингов, добавив уровни 13+, 16+ и 18+, и требует обоснование выбранного значения, а не галочку в форме.

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

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

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

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, проверенные платёжные сценарии, понятная уникальная ценность.

Отдельно стоит снять надежду на альтернативный канал. Закон об обязательной предустановке RuStore формально распространили и на технику Apple, ФАС предписала выполнить требование к 15 июля 2026 года, но срок прошёл, а полноценного российского магазина на iPhone так и не появилось. Для планирования это значит, что канал на iOS один — App Store, и обходных путей у продукта нет.

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

Аккаунт 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-часть встраивается в проект целиком, показано в гайде по созданию мобильного приложения, а что именно проверяют перед релизом — в материале про тестирование мобильного приложения.

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

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

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

Code Pilots проводит проект через все эти рубежи целиком — расскажите о задаче, подскажем, где хватит Flutter, а где нужна нативка, и доведём приложение до релиза в App Store.

Ориентир по деньгам: iOS-приложение мы делаем от 1,8 млн ₽ — на Flutter с публикацией в App Store, урезанная первая версия — от 1 млн ₽. Сюда не входят внешние сборы Apple, о них выше. Точная сумма зависит от функций и интеграций — пришлите задачу, оценка бесплатная.

Прикинуть вилку по своему набору экранов можно в бесплатном калькуляторе оценки.

Мы выпускаем приложения в App Store с 2014 года и знаем цену мелочей: манифест приватности у чужой библиотеки, возрастной рейтинг, свежий инструментарий сборки. Эти вещи не видны в смете, но именно они определяют, выйдет релиз в срок или встанет на неделю.

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

Обсудить проект →