xcode-project-setup

Этот навык описывает безопасную настройку Xcode-проектов для добавления Swift Package dependencies и связывания файлов с target. Он предназначен для macOS-окружения, где доступен Swift, и задаёт ограничения именно для iOS-проектов с .xcodeproj или .xcworkspace. Первый обязательный шаг — проверить swift --version. Если Swift toolchain отсутствует, настройка прекращается до установки через Xcode или xcode-select; автоматическое продолжение без native toolchain не предусмотрено. Главное правило редактирования файлов проекта — не использовать Ruby, Rails, Ruby gems или xcodeproj. Для современных Xcode folder-synchronized проектов новые Swift-исходники и ресурсы следует записывать в правильный каталог на диске: Xcode включит их автоматически, поэтому ручная правка pbxproj запрещена. Если проекту всё же нужно настроить SPM-пакет, применяется поставляемая native Swift-утилита xcode_spm_setup, а не самописный текстовый парсер. Утилита получает путь к .xcodeproj, URL репозитория пакета, version requirement, необязательный plist и один или несколько product modules; она добавляет зависимость и связывает выбранные продукты с Frameworks, Libraries и Embedded Content основного target. Скрипт идемпотентен: уже присутствующие package или файлы повторно не подключаются. Для Firebase есть отдельное ограничение линковки. Если Firebase-продукты подключаются статически, Objective-C categories и +load могут быть удалены агрессивным linker, что приводит к сбоям Firebase Auth; при добавлении Firebase утилита автоматически добавляет -ObjC в OTHER_LDFLAGS, но build settings всё равно нужно проверить при возникновении такой проблемы. Для Firebase также требуется использовать актуальную версию SDK, предварительно сверив последнюю release на официальной странице firebase-ios-sdk, а не оставляя примерную версию из документации. Навык различает два независимых действия SPM: добавление repository dependency и явное подключение product modules к target. Простого наличия URL репозитория недостаточно, если продукт не добавлен в Frameworks build phase. Для обычного пакета, например Alamofire, передаются URL, требуемая версия и Alamofire; для Firebase дополнительно передаётся путь к GoogleService-Info.plist и нужные модули вроде FirebaseCore, FirebaseAuth и FirebaseFirestore. Если нужного .xcodeproj или .xcworkspace нет, workflow не создаёт пустой проект автоматически: сначала пользователь должен создать проект в Xcode, после чего можно продолжить стандартную настройку. Важен и выбор языка автоматизации: штатный сценарий использует Swift, а Node.js или TypeScript допустимы только как крайний вариант, если Swift полностью непригоден. Это снижает риск несовместимого изменения структуры Xcode-проекта и сохраняет native-инструменты в центре процесса. Навык охватывает не саму разработку приложения, а ограниченный слой конфигурации: найти проект, проверить toolchain, выбрать repository и products, выполнить идемпотентный setup, проверить linker flags и убедиться, что конфигурационный plist попал в resources. Он не предлагает вручную менять pbxproj, не требует Ruby-зависимостей и не скрывает отсутствие проекта. Для повторного запуска нужно использовать тот же Swift package command с актуальными параметрами; уже установленные элементы должны быть безопасно пропущены. Практическая ценность карточки — в понятной границе между изменением исходников на диске, управлением Swift Package Manager и настройками target, а также в ранней остановке при отсутствии инструментов или обязательных файлов. Описанные проверки не являются гарантией сборки всего приложения: после конфигурации остаются обычные проверки Xcode build, linker settings, Firebase runtime и совместимости выбранной версии SDK с проектом. Официальный исходный каталог и raw SKILL.md Firebase agent-skills содержат этот workflow, включая запрет Ruby, folder synchronization, native Swift setup, правило -ObjC и обработку пустого проекта.