Bitrise: Make iOS Builds Faster - Tokyo 2019 March - Cookpad meetup

1. Introduction to Bitrise
Hendrik Haandrikman
VP of Growth
rik@bitrise.io
Hhaandr
Introduction and iOS onboarding
Tamas Bazsonyi
Global head of Support
Bazsca

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. Bitrise and
Unicorns
Many of the world’s
most highly valued
startups use Bitrise
to maximize
developer efficiency,
minimize time
wasted onboarding
and ensure that
developer time is
spent on tasks that
bring the company a
competitive
advantage

5. Bitrise and
Japan
Japan is our #2
market worldwide..
Over 20% of our first
1.000 sign-ups
originated there and
today, some of
Japan’s most well-
known developers
build on Bitrise.

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

7. Adding a new iOS project
Scanner is open source:
https://github.com/bitrise-core/bitrise-init
Used in the Step:
https://github.com/bitrise-steplib/steps-project-scanner
Used in the plugin:
https://github.com/bitrise-core/bitrise-plugins-init

8. iOS code signing
codesigndoc
You need the development
certificate and provisioning
profile even for App Store
signing - this is one of the most
common issues
Use our codesigndoc open
source tool
Analyses the project and
collects signing files from your
Mac
Guide: https://devcenter.bitrise.io/code-signing/ios-
code-signing/collecting-files-with-codesigndoc/

9. iOS Auto
Provisioning
Step analyses the project
during the build
Connects to Apple Developer
Portal, generates the right
profile(s) and downloads them
Needs the certificate (private
key) - codesigndoc can be
used for getting that!
Guide: https://devcenter.bitrise.io/code-signing/ios-
code-signing/ios-auto-provisioning/

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

11. 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.

12. 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).

13. 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.

14. 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)

15. 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.

16. 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.

18. 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

19. 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/

20. Carthage - GitHub Access Token
GitHub
Personal
Access
Token

21. 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.

22. 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.

23. 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

24. 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.

25. 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.
Our Xcode Test step has a related optimization: it starts
to boot the simulator before it'd compile & run the test.
Pre-boot iOS Simulator

26. 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

28. 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

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