Bitrise: How to make iOS builds faster - Tokyo 2019 March - Eureka meetup

1. Faster iOS builds on Bitrise
Hendrik Haandrikman
VP of Growth
rik@bitrise.io
Hhaandr
Plus some secret roadmap stuff.
Shhhh...
Viktor Benei
CTO
viktor.benei@bitrise.io
Tokyo, 2019 March

2. THANK YOU

3. Enabling mobile app
developers to do their
best work
What do we do?
Bitrise automates
mobile app integration,
testing and deployment
to make developers
more consistent, faster
and freeing up their
time and talents for the
work that matters.
Bitrise Founding
Founded in 2014 by app
development agency
alumni (Bitfall), looking
to improve their own
process. Y Combinator
backed with $ 3.5M in
funding.
By the numbers
100K developers
15K+ unique apps
1M+ builds / month
50% of mobile unicorns
Headquarters
Headquartered in
Budapest, Hungary,
office in London, remote
in USA, France & more.

4. 日本での採用開始！
Budapest, HU Remote (JP?)London, UK

5. Outlyer
Acquisition
The team and
technology used for
monitoring at Netflix,
BBC, Salesforce
Repurposed to
become a Bitrise-
integrated APM
(Application
Performance
Monitoring) tool for
mobile developers
with millions of
metrics

6. Make iOS Builds Faster
Faster iOS Builds on Bitrise.io
Viktor Benei
viktor.benei@bitrise.io
Tokyo, 2019 March

7. Quickest -> More complex
Starting from easiest, which takes the least amount of
time to configure, progressing towards more advanced
and complex techniques which might require project or
more significant configuration changes.

8. Elite machines
No change required anywhere in the config or in your
project.
Usually 20-50% faster (depends on the project, you get 2x
the CPU and RAM but not network or I/O).

9. Linux stack
Use Linux stack when possible - newer generation CPUs
compared to the aging MacPROs and more RAM.
SPM based projects, e.g. Swift server apps or CLIs.

10. Cache steps
https://devcenter.bitrise.io/caching/about-caching/
Cache:Pull and Cache:Push
Use Bitrise steps, those have built in support. If you use
another tool instead, like fastlane, it works, but you'll have
to specify the dirs/files to cache.
Another example: CocoaPods & Carthage steps
(dependency management steps in general)

11. Keep the Cache small
If you set custom Cache paths make sure you only
include the files & dirs you need, to keep the cache size
small. Smaller cache is faster (download, uncompress,
compress, upload).
You can check the cache content on Settings tab, you
can download the caches from there too for inspection.

12. Parallel build
- https://devcenter.bitrise.io/builds/triggering-
builds/trigger-multiple-workflows/
- https://blog.bitrise.io/start-multiple-builds-with-the-
same-trigger
Needs 2+ concurrencies.
Today it uses Steps, lower level support is coming soon.

14. Parallel build
Few ideas:
- Do Xcode Test, Xcode Analyze and Swift Lint in parallel
- Split your Xcode Test into multiple Targets/Schemes
- Run Test and Archive for internal QA in parallel

15. Bitrise Device Testing feature
Use Bitrise built in (Firebase) Device Testing if you want
to run the test on multiple devices.
https://devcenter.bitrise.io/testing/device-testing-for-ios/

16. Carthage - GitHub Access Token
GitHub
Personal
Access
Token

17. COMPILER_INDEX_STORE_ENABLE
=NO
https://twitter.com/steipete/status/1100404024224804871
- xcode-test:
inputs:
- xcodebuild_test_options: COMPILER_INDEX_STORE_ENABLE=NO
Only helps Debug/non release builds.

18. Use latest Bitrise step versions
We add both reliability and performance optimisations.
E.g. latest Xcode Test step uses headless mode by
default, which can make the tests significantly faster.

19. When deploying multiple .ipa files (e.g. one for ad-hoc
and another one for app-store release) use only one
Xcode Archive & Export for iOS
(https://www.bitrise.io/integrations/steps/xcode-archive)
step and then the Export iOS and tvOS Xcode archive
step (https://www.bitrise.io/integrations/steps/export-
xcarchive) for additional .ipas.
Multiple IPAs in the same build

20. Git Clone: set fetch size to 1/10/20
If the history isn't enough, e.g. PR build, the step will
automatically fetch more. For commit based builds it can
save a lot of time.
Clone Config > Limit fetching to the specified number
of commits
- If most of your builds are PR builds with multiple commits in
it, set it to 10-20 (average commit length in your PRs).
- You can’t use this if you depend on the whole git history to
be available, e.g. for tagging, that’s why this isn’t the default.

21. Boot the iOS Simulator at the start of the build, so that it
will be booted & ready by the time you run your tests in it.
open
"/Applications/Xcode.app/Contents/Developer/Applications
/Simulator.app" "--args" "-CurrentDeviceUDID" "290D8EE7-
A4AB-4004-B07C-5EF784DE30E9"
https://gist.github.com/godrei/16ce30f2a42d6544e49f56cadff9ff7b
Our Xcode Test step has a related optimization: it starts to boot the
simulator before it'd compile & run the test in non-headless mode.
Pre-boot iOS Simulator

22. Remove unused/unnecessary steps.
E.g. use GitHub protected branch & enable Require branches to
be up to date before merging to not to allow push to master (and
make sure you enable Pull Request builds on Bitrise and require
the /pr status check on GitHub), then remove the Test steps from
the deploy workflow as builds will have to go through PR first. This
way the PR can only be merged if it already passed the tests*.
*Bitrise PR build tests the pre-merged code, merges the PR source into its target
during the build to test the code state after merge.
Remove unnecessary steps

24. Collection of tips
- https://devcenter.bitrise.io/tips-and-tricks/optimize-
your-build-times/
- Track function compilation time:
http://khanlou.com/2016/12/guarding-against-long-
compiles/
- https://github.com/fastred/Optimizing-Swift-Build-
Times
- https://medium.com/@bitrise/60-faster-builds-force-
xcode-to-use-caching-on-bitrise-af8979ca39a6

25. Thank you!
Twitter: @viktorbenei
I’ll share the slides on my Twitter.