Travis CI: what it is, features and use in application development

What is Travis CI and How It Works

Travis CI is a cloud-based continuous integration service that automatically runs builds and tests when changes are made to a Git repository. After connecting a repository via GitHub or Bitbucket, Travis CI tracks new commits, Pull Requests, and tag creation, executing the configuration from .travis.yml in an isolated virtual environment.

The Travis CI workflow consists of three stages: trigger (push or Pull Request), environment setup (install), and task execution (script). The service automatically selects a virtual machine with a pre-installed toolset — macOS images with Xcode are available for iOS, Linux images with Android SDK and API levels are available for Android.

Travis CI supports Build Matrix — a mechanism for parallel execution of the same configuration with different parameters. For example, you can simultaneously test an iOS application on Xcode 15 and Xcode 16, and an Android application on API 33 and API 34. Each combination runs on a separate virtual machine, reducing overall validation time.

Travis CI vs Other CI/CD Systems for Mobile Projects

Travis CI differs from Jenkins and GitLab CI in its focus on ease of setup and no infrastructure costs. Jenkins requires installation on your own server and agent configuration, GitLab CI requires a self-managed or cloud GitLab instance. Travis CI works on a subscription basis and requires no server administration.

Compared to GitHub Actions, Travis CI provides more mature macOS images for iOS builds and detailed mobile development documentation. GitHub Actions, on the other hand, is better integrated with the GitHub ecosystem and has more community actions for specific mobile build tasks.

For Android development, Travis CI offers ready-made images with Android SDK 34, Gradle 8, and emulator support. Build startup time is 45–90 seconds, comparable to competitors. The main limitation is the parallel build limit, which depends on the pricing plan.

Travis CI Architecture and How It Works

The Travis CI architecture is built on microservices that manage the job queue, virtual machine allocation, and result processing. Upon receiving a webhook from GitHub, the platform places the job in a queue, finds an available virtual machine with the appropriate language image, and executes the commands from .travis.yml.

Each build runs in an isolated environment with a clean OS image. Travis CI supports three environment types: Ubuntu Linux (standard), macOS (for iOS and macOS builds), and Windows (for .NET and UWP). For mobile projects, support for macOS images with pre-installed Xcode and Fastlane is critical.

The build lifecycle includes phases: before_install (system setup), install (dependency installation), before_script (test preparation), script (running tests and builds), after_script (cleanup). Each phase is optional and configurable in the YAML file.

Build Matrix in Travis CI

Build Matrix allows testing an application with different language, SDK, or environment versions in parallel builds. The matrix is defined using the language, os, env keys and includes automatic generation of all possible combinations. For mobile projects, this is convenient for checking compatibility with different iOS or Android API versions.

When using the matrix, Travis CI launches a separate virtual machine for each combination. This increases overall build minute consumption but is critically important for projects supporting multiple OS versions. Limit the matrix size to 4–6 combinations for optimal coverage-to-cost ratio.

.travis.yml Syntax

The .travis.yml file uses YAML format and consists of root keys: language, os, dist (distribution version), before_install, install, script, and deploy. Each key can contain a string, command array, or dictionary for more complex configuration. Travis CI processes keys in strict order, ensuring build execution predictability.

For iOS projects, the osx_image key with the Xcode version is mandatory, e.g., xcode15.2. For Android — the android key with SDK components. Travis CI supports the deploy key with providers for automatic artifact upload to App Store Connect, Google Play, Firebase, or GitHub Releases after a successful build.

# .travis.yml with Build Matrix for iOS
language: objective-c
os: osx
osx_image: xcode15.2
env:
  - SCHEME=App-iOS
  - SCHEME=App-tvOS
script:
  - xcodebuild -scheme $SCHEME clean build test

Configuring .travis.yml for iOS Projects

For iOS projects, .travis.yml should specify objective-c or swift as the language, the Xcode version via osx_image, and dependency installation via CocoaPods or Swift Package Manager. Travis CI supports all current Xcode versions, including Xcode 16 with iOS 18 SDK, allowing you to test applications on the latest APIs.

An important step is managing certificates for code signing. Use Travis CI encrypted files to store provisioning profiles and certificates in the repository. Fastlane Match is also supported through encrypted TRAVIS environment variables, simplifying signing setup for AdHoc and App Store builds.

# .travis.yml for iOS application with Fastlane
language: swift
os: osx
osx_image: xcode15.2
branches:
  only:
    - main
    - /\d+\.\d+\.\d+/
before_install:
  - gem install cocoapods
  - gem install fastlane
install:
  - pod install --repo-update
script:
  - fastlane scan
  - fastlane gym

For projects with UI tests on XCTest, use the destinations key in xcodebuild to specify the simulator. Travis CI supports running iOS simulators on macOS images without additional configuration — the simulator starts automatically when executing the xcodebuild test command.

Configuring .travis.yml for Android Projects

For Android projects, .travis.yml is configured with the android language and SDK components specified via the android key. Travis CI provides Linux images with pre-installed Java JDK 17, Gradle, and base Android SDK. Additional API levels and build-tools are installed via sdkmanager in the before_install phase.

A key optimization for Android builds is caching the .gradle and .m2 directories. Travis CI supports caching through the cache key, reducing dependency installation time from 120 seconds to 10–15 seconds on subsequent builds. Specify cache paths for Gradle wrapper and Android Gradle Plugin.

# .travis.yml for Android application
language: android
dist: jammy
jdk: oraclejdk17
android:
  components:
    - tools
    - platform-tools
    - build-tools-34.0.0
    - android-34
    - extra-google-m2repository
before_script:
  - yes | sdkmanager "platforms;android-34"
script:
  - ./gradlew assembleDebug testDebugUnitTest
cache:
  directories:
    - $HOME/.gradle/caches/
    - $HOME/.gradle/wrapper/

To run instrumented tests on an Android emulator, add a before_script stage with emulator startup and wait for readiness. Travis CI supports KVM hardware acceleration on Linux images, significantly speeding up UI test execution compared to software emulation.

Travis CI Integration with GitHub and Bitbucket

Travis CI integrates with GitHub and Bitbucket via an OAuth application that adds a webhook to the repository for automatic notification of new commits. After activating the repository in Travis CI, all pushes and Pull Requests automatically trigger a build, and the status (passed, failed, pending) is displayed in the GitHub interface.

Integration with GitHub Pull Request is a key Travis CI feature. The build status is displayed directly in the PR, blocking merging on failed tests. Configuring branch protection in GitHub together with Travis CI ensures that only tested code reaches the main branch.

Travis CI supports encrypted environment variables for storing App Store Connect tokens, Google Play service accounts, and signing keys. Variables are encrypted via the travis encrypt CLI and added to .travis.yml, ensuring secure transfer of sensitive data to the build.

Working with Encrypted Files

Encrypted files in Travis CI allow storing iOS provisioning profiles and certificates in a GitHub repository without risk of leakage. The file is encrypted using the travis encrypt-file command and decrypted automatically during the before_install stage. This is the standard approach for teams using Travis CI for iOS app delivery.

Travis CI Advantages and Limitations

The main advantage of Travis CI is zero infrastructure costs. The team does not need to set up a server, install CI/CD software, or monitor its availability. All management comes down to editing .travis.yml in the repository. The free plan for public repositories makes Travis CI a popular choice for Open Source mobile projects.

The limitation of Travis CI is the build time limit and parallel job limits on pricing plans. For teams with high commit frequency (20+ per day) and long integration tests, cloud minute costs may exceed the cost of maintaining your own Jenkins server. Travis CI also does not support custom Docker images on the free plan.

For mobile development, Travis CI is suitable for teams that use GitHub, have fewer than 10 developers, and do not require custom build infrastructure. For Enterprise projects with Compliance requirements or the need to build on custom macOS machines, Jenkins remains a more flexible solution.