Useful Fastlane built-in actions

Feb 17 2025

Introduction

We’re programmers. We love writing code. But, there are always going to be some edge cases that we didn’t think about, something that we didn’t test against (if we test at all 😉), or some way to use our code that we didn’t intend for. Well, luckily for us, most of the time, someone else has already thought of that edge case and has written an action that probably already does what we want to do.

I’m not talking about the big known actions like scan or pilot or gym. I’m talking about the little guys, the ones that you might not have heard of, or the ones that you might not have thought to use.

The beauty about these actions is that you don’t even need to have Fastlane setup in your project to use them! As long as you’ve got Fastlane installed on your machine, you can just use them with fastlane run <action>.

Incrementing versions

Remember when we wrote our own lane to increment SPM version numbers? Well, I’m sure you’ve been thinking about writing the same kind of logic for incrementing your build and app version numbers. This is something we do a lot, when we release TestFlights, when we release to the store, when we release to internal testers, etc.

Well, you’ll be happy to know that Fastlane has a built-in action for those! The first one is increment_version_number. Just running it with a simple fastlane run increment_version_number will increment version’s patch (assuming you’re using semantic versioning, and if you don’t - you should be). You can also use it to increment the minor or major versions, or even set the version to a specific number.

The sister-action to this is increment_build_number. This one is a bit more straightforward, as it only increments the build number. You can also set the build number to a specific number, or even increment it by a specific number.

Git

This is a bit of an over-arching one, but I’m sure that if you’ve spent more than 5 minutes working on your own Fastlane code, you’ve done something like sh("git add .") or some other kind of hacky way to interact with git. Well, there are actually built-in actions for almost all of the common git actions, so you don’t need to do that anymore!

There’s git_add, which allows you to add either everything, or just specific files and directories. git_commit, that allows you to commit the code you’ve just added, and of course, git_push, that allows you to push your code to the remote.

But there are also some other git built-in actions that you may not know about, like ones to create a pull request, or get the changelog between commits.

Some fun ones

It’s not always business up in here. There are also some fun built-in actions to spice your life up a bit. One of my all-time favorites is say, which makes the machine speak the given message out loud. This is weirdly useful for when you’re running something locally, like a release or a test, and you want to do it in the background and know when it’s done. You can be an adult and have it say things like “done”, but I like putting it in exceptions in my code, so when something goes wrong it says “oh no, poopoo”. It’s unironically a great way to know when a background task is done.

The opposite of it is, of course, rocket! All this action does is print out an ASCII rocket. Granted, the rocket is a bit… phallic looking. But it’s a fun thing to put at the end of long lanes that you know are going to take a while, just to give you a little bit of joy at the end of it.

Summary

So these are just some of my most used built-in actions from Fastlane. There are of course more of them available, and even MORE than those if you just search for the actions on Fastlane (but those won’t be “official”, so might not be as battle tested). And of course, you can always write your own Fastlane action! Let me know if you have any favorite built-in actions, or if you’ve written your own!