Enabling mobile app
developers to do their
What do we do?
mobile app integration,
testing and deployment
to make developers
more consistent, faster
and freeing up their
time and talents for the
work that matters.
Founded in 2014 by app
alumni (Bitfall), looking
to improve their own
process. Y Combinator
backed with $ 3.5M in
By the numbers
15K+ unique apps
1M+ builds / month
50% of mobile unicorns
office in London, remote
in USA, France & more.
Many of the world’s
most highly valued
startups use Bitrise
and ensure that
developer time is
spent on tasks that
bring the company a
Japan is our #2
Over 20% of our first
originated there and
today, some of
Japan’s most well-
build on Bitrise.
Adding a new iOS project
Scanner is open source:
Used in the Step:
Used in the plugin:
iOS code signing
You need the development
certificate and provisioning
profile even for App Store
signing - this is one of the most
Use our codesigndoc open
Analyses the project and
collects signing files from your
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!
Make iOS Builds Faster
Faster iOS Builds on Bitrise.io
Tokyo, 2019 March
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.
No change required anywhere in the config or in your
Usually 20-50% faster (depends on the project, you get 2x
the CPU and RAM but not network or I/O).
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.
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)
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,
You can check the cache content on Settings tab, you
can download the caches from there too for inspection.
Needs 2+ concurrencies.
Today it uses Steps, lower level support is coming soon.
- 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
Bitrise Device Testing feature
Use Bitrise built in (Firebase) Device Testing if you want
to run the test on multiple devices.
Carthage - GitHub Access Token
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.
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
step and then the Export iOS and tvOS Xcode archive
xcarchive) for additional .ipas.
Multiple IPAs in the same build
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
- 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.
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
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
Collection of tips
- Track function compilation time:
I’ll share the slides on my Twitter.