Разработка
Почему xcodebuild работает медленнее, чем Xcode?
Если вы, как и я, заметили, что xcodebuild работает медленно, не волнуйтесь. Вы не один такой.
С тех пор как я перешел на 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, когда вы хотите запустить свое приложение. Может быть…