Xcode 16 Builds very slowly

[marionbarker]

Describe the bug

Initial builds with Xcode 16 are significantly (many minutes) slower than with Xcode 15. This happens for a new clone and any time an existing clone is reset using Product->Clean Build folder.

Configuration

Build times reported in this Issue were obtained with

• LoopWorkspace dev, commit a32a19d (3.5.0)
• Apple M1 MacBook Pro
• Xcode 16.0
• macOS 14.6

Previous Information

The initial discussion of this topic is on zulipchat:

• https://loop.zulipchat.com/#narrow/stream/144182-development/topic/Xcode.2016.20Slow.20Builds

The gist is that when this parameter, ENABLE_MODULE_VERIFIER is set to YES in the project.pbxproj file, the initial build takes a long time with Xcode 16.

Additional Information

There are 19 submodules used by LoopWorkspace 3.4.1 and 3.5.0.

Of those, only 6 submodules have the ENABLE_MODULE_VERIFIER set in the Debug and Release sections and in all cases, it is set to YES. The number of entries in the project.pbxproj file per submodule is shown in the table below.

Repo	Instances
AmplitudeService	4
LibreTransmitter	4
LoopKit	7
MixpanelService	6
OmniBLE	2
OmniKit	6

Suggested Fix

There are 2 suggestions for fixing this problem.

1. Change the instances of that configuration from YES to a parameter that defaults to NO but could be modified to change the value without modifying the submodules again.
2. Remove the lines with that parameter in the project.pbxproj files completely

The rationale for Option 1 is that someone turned these on and there may be a reason why this was done.

The rationale for Option 2 is to be consistent with all the other submodules.

Both these options were tested and the improved timing is identical for either choice so long as the 12 instances of ENABLE_MODULE_VERIFIER = YES that matter are modified.

Timing Data

The timing for the build is taken from the Xcode tool.

• All tests with Xcode 16.0
• All initial builds preceded by Clean Build Folder, close workspace, open workspace
• Use the menu sequence: Product, Perform Action, Build with Timing Summary
• All times are reported in seconds
• View the Build Timing Summary display

Report build time in seconds for first and subsequent builds in the table below. Multiple tests of a given configuration gave consistent results.

Config	First Build	Next Build
dev	490	20
modified	140	20

Timing Display for Initial Build: dev

The graphic below shows the timing display associated with the ENABLE_MODULE_VERIFIER = YES parameter for the initial build for Loop 3.4.1 or 3.5.0.

The items in the graphic above that begin with "Verify" are shown in the list below.

1. LoopKit
2. LoopKit-watchOS
3. LoopKitUI
4. AmplitudeService
5. AmplitudeServiceUIKit
6. MixpanelService
7. MixpanelServiceUI
8. OmniKit
9. OmniKitUI
10. OmniBLE
11. LibreTransmitter
12. LibreTransmitterUI

Timing Display for Initial Build: fix applied

The graphic below shows the timing display for the initial build when the submodules have the suggested fix applied.

[marionbarker]

Based on @gestrich comment in zulipchat, I looked at blame for these 6 modules.
Bill's comment:

I don't think it will make a difference if you will set them to NO vs removing the lines in terms of how it works (assuming Xcode is defaulting to this being off when the line was removed).

There is a slight chance an Xcode update or migration would lead to Xcode writing those lines back to the file automatically. Xcode sometime's does maintenance to the project file to fill in certain missing things. So personally I'd probably set to NO to be explicit but that's a very minor consideration without evidence that will happen for this setting.

Given the fact that I trust Bill over myself, I would have selected Option 1. And Deniz had a few comments sent via personal messages.

The blame results (these lines were added as part of commits for other changes), reinforced what Bill said.

I suggest that Option 1 - set the parameter explicitly instead of removing it - is the better fix for this issue.

Summary of Blame results

Look at blame: (save figures as blame-submodulename.png)

AmplitudeService: ps2; 2023-04-23; comment: Xcode project updates; LoopKit/AmplitudeService@99c2172

LibreTransmitter: ps2; 2023-06-23; comment: Updating to use DisplayGlucosePreference; LoopKit/LibreTransmitter@1ef522f

LoopKit: ps2; 2023-05-08; comment: Update project, and fix build warning; LoopKit/LoopKit@4f30d43

MixpanelService: Camji55; 2023-05-30; comment: Initial commit; LoopKit/MixpanelService@61b9c59

OmniBLE: ps2; 2023-05-06; comment: Cleanup unused files; LoopKit/OmniBLE@dbfa4b6

OmniKit: ps2; 2023-05-06; comment: Cleanup unused files; LoopKit/OmniKit@fa10903

Blame figures

AmplitudeService

LibreTransmitter

LoopKit

MixpanelService

OmniBLE

OmniKit

[marionbarker]

Final Test. Used the dnzxy:module-verify branch for the submodules in the 6 PR. (Option 1 fix).
Downloaded latest version for each at 2024-10-01 08:10 am PDT.

The Xcode 16.0 timing display for the initial build of LoopWorkspace dev with the 6 PR applied is shown below. The build time is down to ~140 sec, compared to ~490 sec before making this modification.