Want to offer native, in-app customer service to your users? Get going quickly with Zendesk’s Mobile SDKs. Free with Zendesk.

It's another fastlane Friday! Last week in Bite #135, we covered how to install and setup fastlane and an initial Fastfile. Today we'll look at how we can take our fastlane skills to the next level and customize our Fastfile using actions. Let's get started.

We briefly mentioned fastlane actions in Bite #135. Let's start by taking a closer look at them.

Actions are essentially build "steps". fastlane organizes these build steps into sets called lanes. Each action is responsible for a very specific part of the lane's larger task.

Let's add an action to a lane:

lane :beta do

By simply adding the increment_build_number action, we'll never need to manually bump our build number again!

Actions can accept options:

increment_version_number(bump_type: "major")

Or return values:

changelog = prompt(text: "Changelog: ")

There's actions for all of the individual fastlane tools we've covered.

We can install dependencies with actions like carthage and cocoapods. We can deploy with the pilot and deliver actions, or use hockey and crashlytics to upload to those services.

We can notify teammates with slack or archive each release with github_release.

We can even define lanes to bootstrap our dev environment using actions like install_xcode_plugin or dotgpg_environment.

We can "shell out" to a truly custom build script as well:

sh "./script.sh"

Simply put, actions are how to get the most out of fastlane. If we're doing something each time we build or deploy, there's a good chance a fastlane already has an action for it.

If not, we can make our own. Just like the Fastfile itself, actions are written in Ruby. We can generate a new one with:

fastlane new_action

Detailed documentation on all actions is available, and we can check out the full list of 120+ actions with:

fastlane actions