Slow incremental build times with xcodebuild command

Question

Created May ’24

Replies 6

Boosts 7

Views 1.7k

Participants 5

When I compile my Xcode project using the xcodebuild command, I observe long incremental build durations. For example, compiling a new, empty project in Xcode only takes around one second. The same project takes 7 seconds to compile using the xcodebuild command. I've noticed that xcodebuild hangs at the "GatherProvisioningInputs" phase.

Steps to Reproduce:

Create a new Xcode project (iOS app template)
Build the project in Xcode with timing summary enabled

Build the same project from the command line with the following command:

time xcodebuild -destination 'platform=iOS Simulator,name=iPhone 15 Pro,OS=latest'

I would appreciate any insights or suggestions on how to improve the build times when using the xcodebuild command. Thank you in advance for your help!

Boost

Answer 1

nikita_dev OP

Jun ’24

I’ve noticed the same thing, "GatherProvisioningInputs" phase takes a good 20+ seconds of xcodebuild.

Interestingly enough, if I disconnect my mac from the network, this step takes no time at all.

Reading the docs, I assumed that xcodebuild doesn’t do any server communication unless -allowProvisioningUpdates flag is specified.

-allowProvisioningUpdates
      Allow xcodebuild to communicate with the Apple Developer website.
      For automatically signed targets, xcodebuild will create and update
      profiles, app IDs, and certificates. For manually signed targets,
      xcodebuild will download missing or updated provisioning profiles.
      Requires a developer account to have been added in Xcode's Accounts
      preference pane.

Is it an xcodebuild issue or am I missing something?

My invocation is nothing special

xcodebuild build -project {PROJ} -scheme {SCHEME} -derivedDataPath {DERIVED} -destination 'platform=macOS,arch=arm64'

Xcode 15.4, macOS 14.5

0

Answer 2

nikita_dev OP

Jun ’24

Digging a little deeper, I managed to capture the following network requests when running xcodebuild:

Screenshot 2024-06-08 at 5.51.14 PM.png

Combined duration of these is 31 seconds, which very close to the overhead I see when I benchmark xcodebuild.

Given that xcodebuild works fine without network for my purposes (see example in previous post), I wonder why fetching all this data is even necessary 🤔

3

Answer 3

FelixII OP

Jun ’24

I have come to the same conclusion as @nikita_dev. My current workaround is to block network requests to developerservices2.apple.com in my hosts file while using xcodebuild. The issue is still present in Xcode 16.0 beta (16A5171c).

5

Answer 4

ag_jarek OP

Jun ’24

I'm also hitting this problem with xcodebuild. A build that should be taking 2-4s is instead taking over 30s, with all of the additional time spent making network requests during GatherProvisioningInputs. I am also not passing -allowProvisioningUpdates.

0

Answer 5

aaclarke OP

Sep ’24

Not sure if this solution works for everyone, but I found in my case that xcodebuild was reaching out because I had an account defined in Xcode > Settings > Accounts. Once I deleted my account from Xcode, xcodebuild sped up to the same speed as when I unplug my network cable.

But the caveat is that my team's build system doesn't have the "Automatically manage signing" checkbox checked for our projects and is setup to separately manage our certs / provisioning profiles / team identifiers, so removing my account from Xcode isn't a big deal.

0

Answer 6

maxik OP

Oct ’24

Great investigation guys! Indeed those requests are very slow, on my side they take around ~20 seconds:

Blocking developerservices2.apple.com significantly improves build time.

As @FelixII suggested, the solution is to block it in /etc/hosts by adding:

127.0.0.1 developerservices2.apple.com

or probably a better option to use something like Proxyman app to temporarily block/unblock it.

Keep in mind that blocking this domain will probably result in Xcode being unable to automatically register devices, capabilities, etc.

I guess we need to wait for some fix from Apple. Probably some cache?

0