React Native 0.87: как разрабатывать без Mac? Решение для выпуска в 2026

Сборка Android и бизнес-код на Windows проходят успешно, но первая попытка получить iOS-артефакт заканчивается отсутствующим Xcode, Simulator или Apple SDK.

Быстрое решение такое: оставьте JavaScript, TypeScript, Metro и большую часть тестов на Windows или Linux, а Simulator, нативные зависимости, Xcode-сборку, подпись и публикацию передайте Mac. Для нерегулярной работы начните с удалённого Mac, для ежедневной графической отладки рассмотрите локальное устройство, а для команды обычно выбирайте гибридный процесс.

Последнее обновление — 20 сентября 2026 года. Версии React Native и требования Apple сверены по релизу React Native 0.87, официальной документации по настройке среды и материалам Apple по требованиям к отправке приложений.

Эта статья предназначена разработчикам, которые используют Windows или Linux и временно не имеют Mac, но должны довести React Native 0.87 до Apple-проверки и выпуска. Она также пригодится DevOps-инженерам, проектирующим Mac-узел для CI, и техническим руководителям, сравнивающим аренду, покупку и общий Mac-ресурс.

Сначала разделите работу по исполняющей среде

Главная ошибка — считать, что «React Native работает на Windows» или «React Native требует Mac» являются взаимоисключающими утверждениями. На практике проект состоит из нескольких слоёв, и каждый из них имеет собственную границу совместимости.

На Windows или Linux можно оставить:

• редактирование JavaScript и TypeScript;
• работу Metro;
• разработку экранов и бизнес-логики;
• статический анализ, форматирование и часть unit-тестов;
• Android SDK, Android Emulator и Android-сборки;
• подготовку pull request и общие проверки CI.

На Mac должны переходить:

• запуск iOS Simulator;
• проверка iOS SDK и Xcode-проектов;
• установка и сборка Apple-зависимостей;
• изменения в Swift, Objective-C и нативной конфигурации;
• создание Archive;
• экспорт, подпись и передача приложения на публикацию.

Официальная документация React Native прямо связывает iOS-разработку с Xcode и Apple-инструментами. Поэтому успешный запуск Metro или Android-приложения подтверждает только работоспособность кроссплатформенного слоя, но не готовность Apple-части проекта.

У React Native 0.87 есть ещё одна граница: экспериментальная поддержка Swift Package Manager не должна автоматически восприниматься как замена проверенному пути проекта. Если репозиторий использует CocoaPods, сначала воспроизведите именно этот сценарий на Mac. Миграцию менеджера зависимостей не стоит совмещать с попыткой впервые наладить удалённую сборку.

Предупреждение. Не называйте проект готовым после успешного выполнения npm install или запуска JavaScript-тестов. Минимальное доказательство готовности — чистый клон, установка нативных зависимостей, Xcode-сборка и проверка результата на Simulator или устройстве.

Симулятор требует графическую сессию, а сборка — командный канал

Удалённый Mac может закрыть потребность в Simulator, но только если у вас есть полноценная графическая сессия. Одного SSH недостаточно: через SSH удобно устанавливать зависимости, выбирать Xcode, запускать xcodebuild и читать логи, однако интерфейс Simulator требует доступа к рабочему столу.

Практическое разделение выглядит так:

• через удалённый рабочий стол вы открываете Xcode, запускаете Simulator, проверяете навигацию, клавиатуру, разрешения, поворот и поведение интерфейса;
• через SSH вы выполняете yarn, npm, pod install, тестовые команды и сборочные скрипты;
• в CI вы повторяете командный путь без ручного открытия Xcode;
• на физическом устройстве отдельно проверяете функции, которые Simulator не воспроизводит с достаточной точностью.

Apple описывает запуск приложения как на Simulator, так и на подключённом устройстве в официальной документации по работе приложения в Xcode. Это важно для планирования приёмки: Simulator подтверждает, что приложение запускается в выбранной программной среде, но не доказывает корректность работы камеры, Bluetooth, push-уведомлений, производительности графики или поведения конкретного устройства.

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

1. графическая сессия не теряет рабочий стол при подключении и отключении;
2. SSH-сессия видит тот же проект, тот же аккаунт и тот же набор инструментов;
3. Simulator запускается из удалённой сессии и отображает приложение;
4. командная сборка завершается без ручного вмешательства;
5. после повторного подключения вы можете продолжить диагностику, а не восстанавливать окружение с нуля.

Для такой проверки полезно заранее изучить методику приёмки удалённого Mac и Xcode-среды. Даже если вы планируете пользоваться машиной только несколько дней, отсутствие графического канала обнаружится слишком поздно — уже во время проверки интерфейса.

Нативные зависимости превращают «обычный» проект в Mac-задачу

Пока вы меняете только React-компоненты, значительная часть работы остаётся независимой от macOS. Ситуация меняется после добавления нативного модуля, изменения AppDelegate, правки Swift или Objective-C, подключения системного разрешения либо обновления библиотеки с CocoaPods-интеграцией.

В этот момент нужно различать три состояния:

• JavaScript-слой успешно установлен и запускается;
• нативный проект корректно сгенерирован или обновлён;
• Xcode действительно собрал приложение и выполнил связанные тесты.

Эти состояния нельзя объединять в один флаг «сборка прошла». Например, зависимость может быть доступна в node_modules, но не попасть в iOS-проект. pod install может завершиться, однако компиляция Swift-файла обнаружит несовместимый API. Наконец, приложение может собраться, но упасть при запуске Simulator из-за неверного разрешения или конфигурации.

Для воспроизводимой проверки используйте отдельную ветку или конкретный идентификатор коммита и выполните следующий цикл:

1. создайте новый рабочий каталог на Mac;
2. клонируйте репозиторий по адресу <REPOSITORY_URL>;
3. установите зафиксированную версию Node.js и менеджер пакетов;
4. выполните установку JavaScript-зависимостей;
5. установите нативные зависимости тем способом, который зафиксирован проектом;
6. проверьте файл конфигурации iOS и идентификатор <BUNDLE_IDENTIFIER>;
7. соберите приложение через Xcode или командный скрипт;
8. запустите его на Simulator;
9. зафиксируйте лог, артефакт и результат теста.

Если используется <TEAM_ID>, сертификат или профиль, подставляйте их только на контролируемом этапе. Не включайте секреты в репозиторий и не копируйте профиль из личной машины без проверки срока действия и назначения.

Результат «чистый клон собирается» намного ценнее результата «проект собирается после ручных исправлений в старом каталоге». Первый показывает, что будущий CI сможет повторить процесс. Второй часто скрывает локальные файлы, кэш, незафиксированные настройки Xcode или случайно сохранённые ключи.

CI должен направлять Apple-этапы на отдельный Mac-узел

Для команды нерационально отправлять всю работу на Mac. Линтеры, проверку типов, документацию, анализ JavaScript и Android-задачи можно оставить на универсальных узлах. Mac-узел следует зарезервировать для тех этапов, где требуются Apple SDK и Xcode.

Рабочее разделение может быть таким.

Универсальный узел:

• установка JavaScript-зависимостей;
• ESLint и форматирование;
• TypeScript-проверка;
• тесты бизнес-логики;
• Android-сборка;
• подготовка исходного архива.

Mac-узел:

• установка CocoaPods-зависимостей;
• сборка iOS-приложения;
• запуск Simulator-тестов;
• создание Archive;
• экспорт артефакта;
• подпись и контролируемая передача на следующий этап.

Mac-узлу нужен отдельный пользователь <CI_USER>, фиксированный рабочий каталог и предсказуемое состояние инструментов. После каждой задачи очищайте временные файлы, проверяйте права каталога и удаляйте чувствительные артефакты, если они больше не нужны. Не превращайте общую удалённую сессию разработчиков в неограниченный CI-аккаунт.

Сопоставляйте три доказательства на одном и том же коммите:

• локальный результат разработчика;
• результат сборки на Mac;
• артефакт, который создал CI.

Если локальный Simulator проходит, а CI получает другую версию SDK или другой набор Pods, проблема находится не в React Native-компонентах, а в расхождении среды. Для проектирования такого процесса пригодится схема размещения Mac-узла для React Native CI.

Подпись и публикация требуют отдельного контура доверия

Собранное приложение ещё не является опубликованным приложением. После компиляции нужно проверить Archive, экспорт, профиль распространения, сертификат, Team ID, Bundle Identifier и сам загружаемый артефакт.

Apple отдельно документирует создание Archive и распространение приложения, а также подготовку проекта к распространению. Эти этапы следует включать в план приёмки, а не оставлять на последний ручной запуск.

С 28 апреля 2026 года Apple требует для отправляемых в App Store Connect приложений Xcode 26 или более новую версию вместе с соответствующим SDK; это требование указано на официальной странице Apple о будущих ограничениях отправки. Поэтому Xcode 27 можно рассматривать только как конкретную установленную версию вашей среды, но не следует заранее объявлять любую конфигурацию с ним совместимой без фактической проверки React Native 0.87, зависимостей и проекта.

Контур выпуска должен включать:

• отдельный аккаунт публикации;
• хранение сертификатов и закрытых ключей вне обычной пользовательской сессии;
• ограниченный доступ к <TEAM_ID> и токенам;
• журналирование команд и инициатора выпуска;
• проверку подписи готового приложения;
• тестовую установку экспортированного файла;
• ручное подтверждение перед отправкой.

Безопаснее сначала выполнить Archive и экспорт без автоматической отправки, проверить результат, а затем разрешить публикационный шаг. Если удалённый Mac используется несколькими людьми, не оставляйте на рабочем столе профили, ключи и незашифрованные токены после завершения задачи.

FAQ: границы разработки без собственного Mac

Windows и Linux подходят для части Apple-разработки

Вы можете вести повседневную работу в основной системе, но должны заранее обозначить момент передачи проекта на Mac. Такой момент наступает не только перед публикацией: он появляется при изменении нативного кода, обновлении CocoaPods-зависимостей и проверке поведения на Simulator.

Удалённый Mac не равен физическому устройству

Удалённый Mac с Simulator удобен для повторяемой проверки интерфейса и автоматизированной сборки. Он не заменяет тестирование на реальном iPhone, если проект использует камеру, Bluetooth, push-уведомления, биометрию или особенности конкретного поколения устройства.

Подпись требует не полного доступа всех разработчиков, а правильного разделения ролей

Разработчик может получить логи и артефакты, тогда как ключ публикации остаётся доступным только защищённому CI-шагу. Такое разделение снижает последствия ошибки в удалённой сессии и упрощает аудит релизов.

Решение по формату оборудования

Ниже приведён инструмент выбора для трёх практических вариантов. Отметьте каждый пункт, который соответствует вашей ситуации, а затем примените условия перехода. Это не оценка абстрактной мощности, а проверка частоты Apple-задач, требования к графическому отклику, безопасности и длительности использования.

Контрольный список удалённого Mac

Выбирайте удалённый Mac как первый вариант, если вы можете отметить большинство следующих пунктов:

• [ ] Apple-сборка нужна время от времени, а не в каждом рабочем цикле;
• [ ] основной редактор и Android-процесс уже работают на Windows или Linux;
• [ ] нужно быстро проверить совместимость React Native 0.87;
• [ ] команда строит временный CI или пилотный проект;
• [ ] вы хотите проверить полный выпуск до покупки оборудования;
• [ ] вам доступны и графический рабочий стол, и SSH;
• [ ] проект не требует постоянного подключения физических устройств.

Если одновременно выполняются первые пять условий, начните с удалённого Mac. Если не выполнены графический доступ или SSH, этот вариант нельзя принимать до устранения ограничения: одной командной оболочки недостаточно для проверки Simulator.

Контрольный список собственного Mac

Рассматривайте собственное устройство, если вы можете отметить следующие признаки:

• [ ] вы ежедневно отлаживаете интерфейс через Simulator;
• [ ] требуется постоянная работа с физическими устройствами;
• [ ] задержка удалённого рабочего стола мешает исследованию UI;
• [ ] Mac будет использоваться длительный срок несколькими проектами;
• [ ] команде нужен локальный доступ к периферии и тестовым устройствам;
• [ ] выпуск и разработка происходят настолько часто, что ожидание удалённой сессии создаёт заметные потери времени.

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

Условия для гибридной схемы

Выбирайте гибрид, если выполняются хотя бы два из следующих условий:

• JavaScript-разработка выполняется на Windows или Linux;
• Apple-сборки должны быть воспроизводимыми для всей команды;
• публикационные ключи необходимо отделить от рабочих аккаунтов;
• Simulator нужен регулярно, но не непрерывно;
• у части команды есть локальные Mac, а у части — нет;
• требуется сохранять Mac-узел для CI даже после покупки локальных устройств.

В гибридной схеме Windows или Linux остаётся основной средой разработки, Mac принимает iOS-сборку, Simulator-тесты и Archive, CI хранит воспроизводимый сценарий, а публикация отделяется от обычной интерактивной сессии. Для командного React Native-проекта это часто наиболее устойчивый вариант.

Пошаговая проверка перед выбором схемы

Выполните проверку на одном настоящем проекте, а не на пустом шаблоне.

1. Зафиксируйте коммит <COMMIT_SHA>, версии Node.js, менеджера пакетов и выбранного Xcode.
2. На Windows или Linux запустите Metro, линтеры, TypeScript-проверку и доступные тесты.
3. На Mac выполните чистое клонирование без копирования локальных каталогов и кэшей.
4. Установите JavaScript- и нативные зависимости согласно файлам проекта.
5. Запустите сборку iOS из командной строки и сохраните полный лог.
6. Откройте проект в Xcode и проверьте запуск на Simulator.
7. Измените небольшой нативный участок, если проект его содержит, затем повторите сборку.
8. Создайте Archive и экспортируйте тестовый артефакт без немедленной публикации.
9. Проверьте подпись, установку и запуск экспортированного приложения.
10. Перезапустите удалённую машину или рабочую сессию и повторите критический участок, чтобы проверить восстановление.
11. Сравните локальный результат, результат Mac и CI-артефакт по одному коммиту.
12. Только после этого решайте, нужен ли постоянный собственный Mac, аренда или смешанная инфраструктура.

Если на шаге чистого клона возникает ошибка, не маскируйте её ручной правкой рабочего каталога. Сначала выясните, не зависит ли сборка от незадокументированного файла, локального сертификата, версии CocoaPods или скрытой настройки Xcode.

Что выбрать в вашем проекте на этой неделе

Если вы пишете код ежедневно, но собираете iOS нерегулярно, не переносите весь проект на Mac и не покупайте устройство вслепую. Начните с удалённого Mac, пройдите чистый клон, Simulator, Archive и повторный запуск, после чего измерьте, где действительно возникает задержка.

У текущей схемы только Windows или Linux есть три системных недостатка: она не даёт полноценного Xcode-цикла, не подтверждает поведение iOS Simulator и не закрывает подпись с публикацией. Общий или случайно настроенный Mac добавляет другие риски — неизвестное состояние зависимостей, конфликт пользовательских прав и утечку ключей. Поэтому для временного проекта аренда VPSMAC даёт более управляемый способ получить Mac-слой без немедленной покупки оборудования; для постоянной графической работы разумнее сопоставить стоимость локального устройства с частотой использования, а Mac-узел оставить в CI.

Начните с одного реального React Native 0.87-коммита и заранее разделите доступ: удалённый рабочий стол для Simulator, SSH для сборки, отдельный контур для подписи. Если такой цикл проходит воспроизводимо, вы уже располагаете достаточным основанием выбрать длительную аренду, покупку собственного Mac или гибридную схему, а не принимать решение по одному успешному запуску JavaScript-кода.