Xcode 27 превращает старые deployment target в ошибки сборки: вот граница

Откройте проект Mac-приложения, который годами собирался без проблем, переключитесь на бета-версию Xcode 27, нажмите Build — и остановитесь:

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

В Xcode 26 эта фраза была жёлтым предупреждением, мимо которого можно было проскроллить. В Xcode 27 это красная ошибка, и сборка не продолжается. Вот и всё изменение целиком, и оно одновременно меньше и больше, чем кажется: меньше — потому что документация Apple годами заявляла нижнюю границу macOS 11 и iOS 15; больше — потому что Xcode никогда её не проверял, а огромное количество работающих приложений незаметно на это полагалось.

В этой статье разобрано, что Xcode 27 реально проверяет (по собственным таблицам и release notes Apple), что реально позволял Xcode 26 (по SDK на нашем собственном диске), кого это затрагивает, недокументированная настройка, которая превращает ошибку обратно в предупреждение, и почему по-настоящему важен не релиз Xcode 27, а требование App Store к SDK следующей весной.

Главные выводы

• Поддерживаемые Xcode 27 deployment target: macOS 12–27, iOS/iPadOS/tvOS 15–27, watchOS 9–27, visionOS 1–27, DriverKit 21–27 — согласно странице поддержки Xcode от Apple для beta 6. Ниже этих значений сборка завершается ошибкой.
• Xcode 26 в документации указывал нижней границей macOS 11, но на практике принимал 10.13. Мы проверили файл настроек SDK macOS 26.0: 34 допустимых deployment target, начиная с 10.13. Xcode 27 закрывает этот разрыв, превращая документированный диапазон в реально проверяемый.
• Нижняя граница для macOS менялась в ходе бета-тестирования. В июне в примечании Apple говорилось о Universal back-deployment «вплоть до macOS 27 включительно»; разработчики прочитали это как Big Sur. В примечании к beta 6 сказано «macOS 12 и новее». Ориентируйтесь на Monterey, а не на Big Sur.
• Есть недокументированный обходной путь — __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO, который, по сообщениям, превращает ошибку обратно в предупреждение. Он официально не поддерживается, может исчезнуть в любой момент и никак не меняет того факта, что Apple не тестирует эти target.
• Настоящий дедлайн — это требование App Store к SDK. SDK Xcode 26 стал обязательным для отправки приложений 28 апреля 2026 года. Если Apple повторит этот паттерн, SDK Xcode 27 станет обязательным примерно в апреле 2027 года, и именно тогда поддержка macOS 11 или iOS 14 в приложении из App Store станет невозможной через обычный канал.

Цифры, официально

Страница поддержки Xcode от Apple публикует таблицу того, для чего может собирать каждая версия Xcode. Вот сравнение, которое имеет значение:

Platform	Xcode 26.6	Xcode 27 beta 6
macOS	11 – 26.5	12 – 27
iOS / iPadOS	15 – 26.5	15 – 27
tvOS	15 – 26.5	15 – 27
watchOS	8 – 26.5	9 – 27
visionOS	1 – 26.5	1 – 27
DriverKit	20 – 25.5	21 – 27

Читайте внимательно: заголовок «Xcode 27 поднимает минимум» верен лишь наполовину. Для iOS документированная нижняя граница была 15 на протяжении всего Xcode 26 и остаётся 15 в Xcode 27. Для macOS она сдвигается на одну версию, с 11 на 12. Для watchOS — с 8 на 9. На бумаге это скромное ужесточение.

А вот что не отражено на бумаге — цифры Xcode 26 никогда реально не проверялись.

Что на самом деле позволял Xcode 26

Каждый SDK внутри Xcode содержит файл настроек, который объявляет, какие deployment target считаются допустимыми. На нашей машине, с установленным Xcode 26.0.1 (17A400), этот файл находится по пути:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json

Чтобы его прочитать, достаточно одной команды:

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

Вывод на Xcode 26.0.1:

10.13 -> 26.0.99
34 valid: ['10.13', '10.14', '10.15', '11.0', '11.1', '11.2'] ...

Итак, пока таблица Apple говорила «macOS 11», SDK говорил «10.13», и Xcode позволял вписать 10.13 в поле deployment target, выдавал предупреждение — и всё равно собирал проект. Майкл Цай (Michael Tsai) описывает эту практику прямо: разработчики «могли вручную вводить более старые target», и множество независимого ПО для Mac именно так и делало, чтобы удержать пользователей High Sierra, Mojave и Catalina на актуальной сборке.

Если у вас установлена бета Xcode 27, выполните ту же команду для её SDK (подставив Xcode-beta.app) — и вы увидите новую границу. На этой машине беты нет, поэтому в отношении цифры 12.0 мы полагаемся на таблицу Apple и сообщения разработчиков, а не на собственное чтение файла.

От предупреждения к ошибке

Сама диагностика не нова. Система сборки Apple годами выдавала сообщение «the range of supported deployment target versions is X to Y» в виде предупреждения. Xcode 27 меняет именно её серьёзность.

Разбор на bleepingswift.com приводит цитату iOS-варианта сообщения, как оно выглядит в Xcode 27:

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

Вариант для macOS — то же сообщение, но с MACOSX_DEPLOYMENT_TARGET и диапазоном от 12.0 до 27.0.99. Оно срабатывает для каждого target отдельно, поэтому приложение с расширением, виджетом и test bundle, унаследовавшими старый target, покажет его четыре раза — и исправление одного только основного приложения не устранит ошибку сборки.

Мейнтейнеры Vienna RSS столкнулись с этим 10 июня, спустя два дня после выхода беты: их target был 10.13, проект собирался без предупреждений и ошибок в Xcode 26, а в Xcode 27 «это стало жёстким требованием (ошибка сборки)». Их дальнейшее беспокойство разделяет каждый Mac-разработчик в такой ситуации: Xcode 26, вероятно, не будет поддерживаться на macOS 27, а значит у запасного варианта «оставить старый Xcode» есть срок годности.

Что изменилось между июнем и beta 6

Нижняя граница для macOS не была стабильной на протяжении всего периода беты, и стоит понимать, какую версию этой истории вы читаете.

В июне примечание об Intel гласило, как процитировано на форумах Apple Developer:

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

В этом нет ни слова о минимуме. В сводке первого дня Цай трактовал ситуацию так: «минимальный target теперь — Big Sur (или Monterey для Mac на Apple Silicon)», а в issue ViennaRSS прямо говорилось о macOS 12. Текущие release notes beta 6 расставляют всё по местам:

Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

Тот же номер issue, но переформулированный с прямым указанием macOS 12. Сентябрьское обновление Цая отмечает то же самое: «Xcode 27 Beta 6 теперь документирует macOS 12.0 как минимальный deployment target». Если ваш план миграции строился вокруг Big Sur, пересмотрите его в пользу Monterey.

Кого это реально затрагивает

Три группы, в порядке убывания боли.

Mac-приложения, всё ещё поддерживающие диапазон от High Sierra до Big Sur

Это та группа, о которой пост Цая, и группа, к которой платформа проявляет меньше всего сочувствия. Маттиас Гансриглер-Храд (Matthias Gansrigler-Hrad) из Eternal Storms прямо высказался в Mastodon:

I don't appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It's my decision

Для этих разработчиков Xcode 27 — вынужденный выбор: поднять нижнюю границу и отсечь пользователей систем 2017–2020 годов или остаться на Xcode 26 и отказаться от SDK macOS 27 и всего, что от него зависит.

iOS-приложения и, особенно, iOS-библиотеки с target ниже 15

Нижняя граница Apple для iOS — 15 начиная с Xcode 26, поэтому приложение, уже стоящее на 15, ничего не замечает. Но экосистема была полна библиотек, объявляющих более низкие минимумы, и каждая теперь выдаёт диагностику в любом проекте, который её импортирует. Трекеры issue на GitHub за первую неделю июня заполнились почти идентичными запросами вида «Support Xcode 27: raise minimum iOS deployment target to 15» — против Facebook iOS SDK, объявившего .iOS(.v12) в своём Package.swift, против Adjust, DataDog, SDWebImage и других. Если вы зависите от пакета, мейнтейнер которого не отреагировал, вы заблокированы до тех пор, пока он не отреагирует — или пока вы не сделаете форк.

Все, у кого старый target спрятан в зависимости

Тонкий случай. Ваше приложение нацелено на 15. Транзитивный Swift-пакет нацелен на 13. Xcode 27 собирает этот пакет вашим toolchain, видит 13 — и валит сборку. В Swift Package Manager нет способа переопределить это со стороны потребителя: вывод bleepingswift, совпадающий с нашим, — «пакеты, объявляющие более старые минимумы в своей декларации platforms, требуют либо обновления до более новой версии пакета, либо форка и самостоятельного изменения требования».

Скрытый обходной путь

Он существует, и о нём стоит знать — и обращаться с ним осторожно.

Ighor July, написавший 24 июля материал, который цитирует Цай, сообщает, что в бете Xcode 27 «скрытая настройка превращает эти ошибки обратно в предупреждения, и компилятор всё ещё собирал более старые target, которые я тестировал». Он описывает эту настройку как «недокументированную, отсутствующую в обычном интерфейсе Xcode и на данный момент существующую только для тестирования» в бета-toolchain. Читатель поста Цая, Харальд Штрипе (Harald Striepe), называет её:

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

Это build setting, поэтому его место — там же, где и остальные настройки сборки: в файле .xcconfig, привязанном к конфигурации, либо в виде User-Defined настройки, добавленной внизу панели Build Settings target. Установите её — и проверка deployment target вернётся к поведению Xcode 26.

Теперь об оговорках, и они немаленькие.

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

Она возвращает предупреждение, а не тестирование. Оценку Цаем всего этого изменения стоит процитировать полностью, потому что она честно расставляет акценты:

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

Отключение ошибки возвращает вас к сборке под target, который Apple и раньше не тестировала, а теперь ещё и прямо не поддерживает. Всё, что было сломано на Catalina в Xcode 26, так и останется сломанным.

Она никак не решает вопрос App Store. А это подводит нас к дедлайну, который действительно имеет значение.

Настоящий дедлайн — апрель 2027

Выход Xcode 27 сам по себе никого не заставляет им пользоваться. А вот требование App Store к SDK — заставляет.

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

Если этот паттерн сохранится — а Apple ещё не объявила дату на 2027 год, так что это прогноз на основе паттерна, а не факт, — то примерно с апреля 2027 года каждая отправка в App Store должна будет собираться SDK Xcode 27. На этот момент:

• Приложение из Mac App Store нельзя будет обновить с deployment target ниже 12.0, потому что единственный toolchain, который принимает магазин, откажется его собирать.
• Приложение из iOS App Store нельзя будет обновить с target ниже 15.0, по той же причине.
• Неизвестно, переживёт ли обходная настройка проверку App Store. Никто не сообщал о том, что тестировал это, и мы бы не стали строить на этом бизнес.

Вне App Store — при прямом распространении через Developer ID — ничего из этого не действует. Вы можете продолжать собирать проекты в Xcode 26 до тех пор, пока Xcode 26 запускается на принадлежащем вам Mac. А это уже следующая проблема.

Держать Xcode 26 под рукой — и почему это перестаёт работать

Очевидное решение — установить обе версии. Инструменты вроде xcodes позволяют легко держать Xcode 26.6 рядом с бетой 27-й версии и переключаться между ними через xcode-select. Для проекта с target 10.13, который вам всё ещё нужно выпустить в этом году, это правильный выбор.

У этого решения есть срок годности. В таблице поддержки Apple для Xcode 26.6 указано требование «macOS Tahoe 26.2 – macOS Tahoe 26.x». Нигде не сказано, что он запускается на macOS 27, и, по мнению Цая, «использование старых версий Xcode — не лучшее решение, потому что они не поддерживаются на Golden Gate». Он может запуститься; а может и нет — и Apple это чинить не будет. И он добавляет более тонкую цену:

Swift also makes it more difficult to call newer APIs when using an older SDK.

Оставаться на Xcode 26 значит оставаться на SDK macOS 26, а это значит, что API macOS 27 доступны только через динамический lookup — или не доступны вовсе. Для приложения в режиме поддержки это нормально. Для всего, что вы активно разрабатываете, — это медленное удушение.

Сам Xcode 27 работает только на Apple Silicon

Это отдельное изменение, которое попало в тот же релиз и путается с историей про deployment target, так что стоит явно разделить, что есть что.

Release notes однозначны: «Xcode 27 будет устанавливаться и работать только на Mac с Apple Silicon». Бинарник — только arm64, что подтвердил на форумах владелец Intel MacBook Pro, подтвердивший это на форумах, после того как строка «requires macOS Tahoe 26.4 or later» в примечаниях заставила его ожидать иного — Tahoe работает на нескольких Intel Mac, а Xcode 27 — нет.

SDK при этом остаётся Universal. Вы можете собирать срезы x86_64 и Universal-бинарники из Xcode 27 — просто делать это придётся на Apple Silicon. Это требование к железу разработчика, а не ограничение на распространение самого приложения.

Ещё одно изменение для Intel: Universal больше не значение по умолчанию для 27.0

Ещё один пункт про Intel в примечаниях к beta 6, помещённый в раздел «Intel Deprecation», который большинство обзоров пропустило:

Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. The x86_64 architecture can be added to the ARCHS build setting if this is needed. (161837535)

Это логично — macOS 27 не запускается ни на одном Intel Mac, поэтому target, ориентированный только на 27.0, попросту не имеет Intel-машин, на которых мог бы работать, — но у этого есть побочный эффект. Rosetta по-прежнему присутствует в macOS 27, и примечание Apple для разработчиков от 1 сентября подтвердило, что 27-я версия — последний релиз. Приложение только для 27.0, которое по умолчанию отбрасывает x86_64, также перестаёт запускаться под Rosetta на Apple Silicon, что имеет значение только если вы поставляли Intel-only хост плагинов или что-то подобное. Добавьте x86_64 в ARCHS явно, если он вам нужен.

Третья граница, о которой никто не говорит: libc++ на уровне 11.0

Спрятано в том же списке Deprecations: «Минимальный поддерживаемый deployment target на macOS для стандартной библиотеки C++ повышен до 11.0». Это отдельная, более низкая граница, чем 12.0 у системы сборки, и она относится к C++ runtime, с которым вы линкуетесь, а не к декларируемому deployment target. На практике она проявляется, только если вы обошли проверку системы сборки — например, скрытой настройкой — и всё ещё нацелены на 10.15 или более раннюю версию с кодом на C++. Тогда следующим препятствием станет уже сам libc++.

Как это чинить: зависимости

Для собственных target исправление — это просто число в текстовом поле. Для зависимостей всё сложнее:

CocoaPods. Добавьте хук post_install, который переписывает deployment target каждого pod-таргета на нужную границу, затем выполните pod install и очистите build folder. Вариант хука от bleepingswift — стандартная форма; суть в том, что он применяется ко всем pod-таргетам, а не только к тем, что жалуются сегодня.

Swift Package Manager. Способа переопределить это не существует. Ваши варианты: обновиться до версии пакета, поднявшей своё platforms; открыть issue или проголосовать за существующий; либо сделать форк, отредактировать Package.swift и направить проект на этот форк, пока апстрим не догонит. Сначала проверьте трекер issue — для крупных SDK кто-то уже подал запрос в первую неделю июня, и обычно к нему приложен pull request.

Vendored-фреймворки и XCFrameworks. У них свой собственный минимум в Info.plist и Mach-O load commands. Xcode 27 не отказывается слинковать старый бинарный фреймворк, но линкер выдаст предупреждение о несовпадении версий, а поведение на старом target протестировано ровно настолько, насколько оно вообще было протестировано — то есть никак.

Что здесь значит «честно»

Стоит на секунду задержаться на формулировке Цая, потому что она меняет то, на что вам вообще стоит злиться.

Xcode 26 не поддерживал macOS 10.13. Он позволял ввести 10.13 и генерировал код, но Apple не тестировала, что фреймворки в SDK 26-й версии корректно работают на операционной системе 2017 года. Разработчики, выпускавшие такие сборки, фактически сами проводили QA против ОС, которую Apple уже оставила позади, и в основном это работало, потому что фреймворки по замыслу обратно совместимы. Но слово «в основном» несло здесь настоящую нагрузку, и с каждым годом разрыв между SDK и target только увеличивался.

Xcode 27 делает документированный диапазон реальным. Это потеря для пользователей старых Mac и для разработчиков, которые их обслуживали. Но это не потеря чего-то, что Apple когда-либо обещала.

Регуляторная загвоздка

Ещё одна нить этой истории. 26 августа Цай собрал комментарии об европейском Cyber Resilience Act, основные обязательства которого вступают в силу 11 декабря 2027 года и который требует обновлений безопасности минимум в течение пяти лет. Читатель, представившийся как Фредерик (Frederik), обозначил связь с App Store:

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

Это ровно тот механизм, который описан в этой статье. У App Store есть только одна актуальная версия на приложение. Если SDK Xcode 27 станет обязательным и ваша нижняя граница поднимется до macOS 12, пользователи macOS 11 навсегда останутся с последней полученной сборкой, без обновлений безопасности. Считает ли CRA это обязательством разработчика, Apple или ничьим — вопрос для юристов; технический же факт в том, что у модели распространения Apple нет механизма веток, и Xcode 27 вот-вот сделает это заметным для гораздо большего числа разработчиков.

Чек-лист миграции

Для Mac-приложения со старым target, по порядку:

1. Проведите инвентаризацию реальных пользователей. Если ваша аналитика говорит, что никого нет ниже macOS 12, это изменение в одну строку и одна строка в release note. Большинство приложений находится именно здесь.
2. Установите deployment target 12.0 (macOS) или 15.0 (iOS) для каждого target, включая расширения, вспомогательные процессы и тесты. Соберите проект в бете Xcode 27 и устраните каждый случай диагностики.
3. Проверьте зависимости на предмет деклараций platforms и podspec ниже нижней границы. Форкните то, что необходимо.
4. Определитесь по отстающим системам. Если вам действительно нужно продолжать поставку пользователям 10.13–11.0, запланируйте финальную сборку на Xcode 26 до апреля 2027 года, распространяйте её вне App Store или как замороженную legacy-версию — и заявите об этом публично.
5. Не отправляйте скрытую настройку в продакшн, если только вы сами не протестировали результат на старой ОС и не готовы к тому, что настройка может исчезнуть в следующей бете.
6. Если ваш target — только 27.0, проверьте ARCHS. Возможно, вы только что незаметно для себя отбросили x86_64.

Решение типичных проблем

Ошибка не исчезает после того, как я поднял target приложения

У другого target в проекте всё ещё стоит старое значение. Выберите проект (не target) в навигаторе, проверьте deployment target на уровне проекта, затем каждый target и каждый test bundle. Виджеты и расширения приложений — обычные виновники.

В ошибке упомянут пакет, от которого я напрямую не зависим

Это транзитивная зависимость. Используйте swift package show-dependencies (или граф пакетов в Xcode), чтобы найти, кто её подтягивает, а затем либо обновите этот промежуточный пакет, либо сделайте форк листового пакета.

xcodebuild из командной строки падает, а GUI Xcode собирает нормально

Проверьте, какой toolchain использует командная строка: xcode-select -p. Возможно, у вас GUI на 26-й версии, а CLI — на 27-й, или наоборот.

Я установил скрытый флаг, но ничего не изменилось

Флаг должен быть виден системе сборки на том уровне, где выполняется проверка — самое безопасное место — xcconfig на уровне проекта. Если он установлен только для одного target, остальные target всё равно будут выдавать ошибку. Если и это не помогает, возможно, ваша бета уже убрала этот флаг.

Мои CI-раннеры на Intel

Xcode 27 на них не установится. Это миграция железа, а не проблема конфигурации. Хостинг-провайдеры уже давно перешли на раннеры с Apple Silicon; self-hosted Intel Mac mini теперь окончательно выведены из строя для сборок актуальным toolchain.

Часто задаваемые вопросы

Xcode 27 поднимает минимум для iOS?

Формально нет — таблица Apple указывает iOS 15 с момента выхода Xcode 26. Меняется именно проверка: target ниже 15, которые собирались с предупреждением в Xcode 26, теперь падают в Xcode 27.

Каков минимум для macOS в Xcode 27?

macOS 12 Monterey, согласно странице поддержки Xcode от Apple и release notes beta 6. Ранее в цикле беты примечание трактовалось как Big Sur; эта трактовка устарела.

Можно ли по-прежнему собирать Universal-приложения (Intel + Apple Silicon)?

Да, с Mac на Apple Silicon. SDK macOS 27 поддерживает Universal back-deployment вплоть до macOS 12 и новее. Единственный случай, когда x86_64 отбрасывается по умолчанию, — это target, установленный на 27.0 или новее.

Когда мне придётся перейти на Xcode 27?

Для прямого распространения — никогда, пока у вас есть Mac, на котором запускается Xcode 26. Для App Store — когда Apple сделает SDK 27-й версии обязательным, что по установившемуся паттерну произойдёт примерно в апреле 2027 года. Apple эту дату пока не объявила.

Безопасна ли скрытая настройка для сборок App Store?

Неизвестно. Никто не сообщал об отправке приложения, собранного с ней, а сама настройка — недокументированный внутренний флаг. Относитесь к ней как к инструменту для локальных сборок и legacy-веток, а не для вашего release pipeline.

Заключение

Изменение deployment target в Xcode 27 — небольшая правка с длинным шлейфом последствий. Apple не сильно подняла нижнюю границу — одну версию для macOS, ни одной для iOS, — но перестала делать вид, что эта граница необязательна, а десятилетие независимого ПО для Mac было построено именно на этом притворстве. Ошибку сборки, которую вы получаете сегодня, легко исправить, если ваши пользователи на современных системах, и невозможно исправить по-настоящему, если нет.

Определите, к какой категории относитесь вы. Если вы всё ещё поставляете приложение для macOS 11 или более ранних версий, оставшееся окно — это Xcode 26 на Mac, который его ещё запускает, и оно закрывается для приложений App Store примерно через семь месяцев. Если нет — поднимите число, почините зависимости, проверьте ARCHS, если вы работаете только с 27-й версией, и двигайтесь дальше: Apple наконец задокументировала то, что всегда собиралась сделать.

Похожие материалы: проверьте свои Intel-приложения до отключения Rosetta, прекращение поддержки Intel в macOS 27, исправление настройки среды разработчика в macOS Tahoe, и лучшие инструменты для Mac-разработчиков в этом году.