Почему xcodebuild работает медленнее, чем Xcode?

С тех пор как я перешел на Cursor для большей части своего рабочего процесса iOS-разработки, я стал меньше работать с графическим интерфейсом Xcode и больше — с его инструментом командной строки, xcodebuild.

Если вы не знакомы с ним, то он используется для сборки проекта без запуска самого приложения Xcode. Если вы запускаете свой проект в CI и/или используете Fastlane, вы определенно использовали эту утилиту, может даже не зная об этом.

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

xcodebuild ARCHS\=arm64 VALID_ARCHS\=arm64 ONLY_ACTIVE_ARCH\=NO -scheme IceCubesApp -configuration Debug -workspace /Users/dimillian/Documents/Dev/Other/IceCubesApp/IceCubesApp.xcodeproj/project.xcworkspace -destination 'platform=iOS Simulator,id=E99971ED-7594-459D-A77E-DF735E47F5B2' -resultBundlePath '/Users/dimillian/Library/Application Support/Cursor/User/workspaceStorage/ceb1a744769b70b7bfd7b78ac51e31d4/sweetpad.sweetpad/bundle/IceCubesApp' -allowProvisioningUpdates build
open -a Simulator
xcrun simctl install E99971ED-7594-459D-A77E-DF735E47F5B2 '/Users/dimillian/Library/Developer/Xcode/DerivedData/IceCubesApp-dckoljloxttnqcekprljivqttvuw/Build/Products/Debug-iphonesimulator/Ice Cubes.app'
xcrun simctl launch --console-pty --terminate-running-process E99971ED-7594-459D-A77E-DF735E47F5B2 com.thomasricouard.IceCubesApp

А затем подключается xcrun для запуска.

Если вы не используете кастомный набор инструментов для сборки, например Bazel, вы привязаны к Xcode или xcodebuild для сборки вашего проекта.

Если вы, как и я, заметили, что xcodebuild работает медленно, не волнуйтесь. Вы не один такой. В настоящее время в xcodebuild есть ошибка. Он выполняет встроенные сетевые запросы при сборке проекта, чтобы проверить наличие provisioning профайлов, даже при инкрементных сборках.

Шаг сразу после Resolving Package Graph — GatherProvisioningInputs, и время, которое xcodebuild тратит на него, кажется, растет вместе с количеством целей в вашем проекте.

Есть способ обойти это, как отмечено в этой проблеме xcodebuild vim extension на GitHub.

Вы можете запретить xcodebuild пинговать сайт, заблокировав доступ к developerservices2.apple.com в вашем /etc/hosts:

sudo bash -c "echo '127.0.0.1 developerservices2.apple.com' >>/etc/hosts"

А затем, когда сборка будет завершена, восстановите доступ:

sudo sed -i '' '/developerservices2\.apple\.com/d' /etc/hosts

Обратите внимание, что пока developerservices2.apple.com заблокирован, Xcode не сможет получить доступ к вашим provisioning-профилям, и IDE удалит ваши учетные записи разработчиков, если вы его запустите. Поэтому не забудьте удалить запись из /etc/hosts.

Эта ошибка присутствует с первой бета-версии Xcode 16.0 и до сих пор присутствует в Xcode 16.1 RC. Будем надеяться, что Apple скоро исправит ее…

Рудранк также написал скрипт, который я вставлю сюда:

#!/bin/bash

# Function to block the domain
block_domain() {
    echo "127.0.0.1 http://developerservices2.apple.com" | sudo tee -a /etc/hosts > /dev/null
    echo "Domain blocked"
}

# Function to unblock the domain
unblock_domain() {
    sudo sed -i '' '/developerservices2\.apple\.com/d' /etc/hosts
    echo "Domain unblocked"
}

# Check if xcodebuild command is provided
if [ $# -eq 0 ]; then
    echo "Please provide the xcodebuild command as arguments"
    exit 1
fi

# Block the domain
block_domain

# Run xcodebuild with all passed arguments
"$@"

# Capture the exit code of xcodebuild
BUILD_RESULT=$?

# Unblock the domain
unblock_domain

# Exit with the same code as xcodebuild
exit $BUILD_RESULT

По сути, это обертка для xcodebuild, которая блокирует/разблокирует домен Apple во время сборки.

Использование:

./xcodebuild-wrapper.sh xcodebuild [usual xcodebuild arguments]

Но, кроме того, он так устроен

Ну, Xcode устроен именно так. По сути, xcodebuild является одноразовым; сервер убивается, как только сборка завершена. Само приложение Xcode работает по-другому. Оно не использует xcodebuild напрямую, а использует множество (приватных) API, которые поддерживают службу сборки в рабочем состоянии, поэтому инкрементные сборки быстрее при сборке из Xcode. Нажатие кнопки build & run всегда будет быстрее, чем выполнение еще одной команды xcodebuid.

Как отмечается на странице Tuist с описанием кэша, они оптимизируют работу с xcodebuild, но не могут сделать многое, пока Apple не предоставит им инструменты, которые они сами используют в Xcode.

Я пошутил, что, возможно, решение заключается в создании расширения для VSCode, которое на самом деле нажимает кнопку сборки и запуска в Xcode, когда вы хотите запустить свое приложение. Может быть…

Источник