iOS Swift: How to avoid compiling twice (for UT and for archive)

Question & Answer
1

As my build time is increased I am profiling every parts of the build.
I already profiled swift compiler times and gain around 4 minutes on the whole build.
But it is still very long (> 30 minutes) for a very basic application.

Thus, I start digging into Bitrise logs, and I found that both Xcode Test and Xcode Archive steps were compiling the application. This lead to a double heavy work.

How to avoid this?

1 Like
2

Unfortunately you might not be able to avoid this, because Xcode’s test action by default compiles your code with the Debug config, while archive is done with Release config.

You can of course try to change this, to e.g. run the tests with the Release config too, but that might cause issues long term.

An alternative solution might be a workflow where you only run Test on Pull Requests, and you only run Archive on Pull Request merge. Something like Using the Trigger Map to trigger builds - Bitrise Docs or Using the Trigger Map to trigger builds - Bitrise Docs

We use this for our main website (bitrise.io), running tests only on the Pull Requests, but this requires some additional configuration / consideration on your source code hosting service. E.g. we prevent any push to master by using GitHub protected branches, enforcing that every PR have to pass the tests before merge, as well as that it have to be “up to date” with master before it could be merged (as well as it have to pass a code review before merge).

3

Are there any other long running steps in your workflow? 30 mins seems to be really really long for a “very basic application”. The test projects we use for continous performance checks are way faster than that:

  • an old, but “fairly complex” ObjC app we wrote years ago can Archive in ~120 seconds
  • a minimal Swift sample project can run Xcode Test in ~120 seconds and Archive in ~45 seconds, the whole workflow (including git clone, xcode test, xcode archive, deploy, …) takes ~3.5 - 4 mins.
4

May I let you access to my build so you can have a look on it?
So far, Xcode Test step takes around 17min and Xcode Archive step takes around 16 min.

5

Sure, feel free to send us the build’s URL in private and we’ll have a look!

You can also enable access for our support account on the Settings tab:

http://discuss.bitrise.io/t/enable-bitrise-support-user-for-the-app/189

6

I gave you access but I don’t find a way to send you a private message.

7

@eaappfactory you can use the “Contact Support” option on bitrise.io - New, unified Support menu

8

I took a look on your project, couldn’t see any build config issue. It seems that your code is simply not that “basic” as you think :wink:

You use for example quite a few CocoaPods dependencies, which have to be compiled too.

You could try to see which dependency / dependencies take a long time to compile, I’d say there’s at least one which requires a long time for compilation.

9

Noticed one build config issue, but that most likely won’t save you as much time as you want to.

You have a workflow called branches with steps in this order:

- cocoapods-install@1.6.1: {}
- cache-pull@0.9.2: {}

You should reverse these two steps, cache pull should be before cocoapods install, or else cocoapods install can’t leverage the cache (as it’s simply not there before the cache-pull step). See:

10

One more thing, we’re experimenting with faster build machines, if you’re interested I can ping you when it’s ready for beta testing @eaappfactory

(there’s a catch, after the beta these configs will cost more, but so far we saw quite significant speed improvements for projects which are cpu intensive)