I wish Fastlane were written in Swift

Did you know you can write Fastlane lanes in Swift?

Technically, yes, but the development experience is a far cry from what you’re used to when working with Swift.

When I first discovered Fastlane Swift, I was over the moon. I immediately created a small demo project and took it for a spin. It took me a while to get it working, only to realize many problems.

Fastlane Swift’s Core Implementation

Even though Fastlane Swift lets you write lanes in Swift, it doesn’t mean Fastlane itself is implemented in Swift. In fact, it isn’t.

If you examine the codebase closely, you’ll see that Fastlane Swift is just a thin wrapper around the original Ruby implementation.

This means you still have to have Fastlane Ruby installed. But there’s a problem.

Fastlane Swift doesn’t respect the Fastlane version set by tools like bundler or mise. It just uses whatever version is installed in your system’s default location. That creates problems in CI setups and makes it impossible to provide a unified development experience for your team.

Public APIs

The public APIs in Fastlane Swift are auto-generated. That’s why they don’t feel anything like what Swift developers expect.

Each action is a 1-to-1 mirror of its Ruby counterpart. For example, the match action is represented like this:

public func match(
  type: String,
  additionalCertTypes: OptionalConfigValue<[String]?>,
  readonly: OptionalConfigValue<Bool>,
  generateAppleCerts: OptionalConfigValue<Bool>,
  skipProvisioningProfiles: OptionalConfigValue<Bool>,
  // and many more parameters...
}

You still need to open the original Ruby documentation to figure out how to use it. There are no clean, intuitive APIs guiding you through the process.

Handling Lane Parameters

Fastlane actions support passing parameters:

$ fastlane run gym project:"/a/path/to/a/project" clean:"true"

Handling parameters in Fastlane Swift is clunky and error-prone. There’s no compiler safety:

// Example from the official Fastlane docs
class Fastfile: LaneFile {
  func deployLane(withOptions options:[String: String]?) {
    // ...
    if let submit = options?["submit"], submit == "true" {
      // Only when submit is true
    }
    // ...
    incrementBuildNumber(buildNumber: options?["build_number"])
    // ...
  }
}

Fortunately, we now have libraries like swift-argument-parser that could make this cleaner and safer.

A Better Way Forward

Swift has evolved, and so should this feature. Reimplementing the foundational pieces of Fastlane in Swift could solve most of these issues.

Let me explain.

Native to Swift Developers

As an iOS developer, I want to write automation in Swift. It’s the language I’m comfortable with and it brings me joy.

If your whole team knows Swift, the barrier to contributing drops. Automation is no longer reserved for the few who know Ruby.

Some may argue that with the rise of LLMs, the language doesn’t matter anymore. I disagree.

These tools can help, but only up to a point. Eventually, someone has to dive deep. And when they do, being in your native language makes all the difference.

Clean and Concise Public APIs

Fastlane has added a lot of features over the years. Keeping backward compatibility means actions like match have ballooned in complexity.

Did you know match supports 54 parameters?

Many of them are mutually exclusive.

Rewriting Fastlane in Swift would be a rare opportunity to start from scratch. Just imagine how the APIs could look:

import FastlaneBuilding

let options = BuildOptions(
  scheme: "MyApp", 
  configuration: "Debug", 
  platform: .iOS(.v17)
)
try await FastlaneBuild().buildProject(at: path, with: options) 

Concise. Type-safe. Easy to use.

No More Ruby Versioning

You wouldn’t need to worry about managing Ruby versions anymore. Tools like mise make it easier, sure — but it’s still another layer of friction. One less thing to deal with is always a win.

Compiler Safety

Interpreted languages are great for prototyping. But my Fastlane lanes aren’t prototypes. They’re production code. I’m happy to trade a bit of prototyping speed for long-term reliability.

Attracting New Contributors

Developers love shiny new things. A Swift-native Fastlane would scratch that itch and attract fresh contributors who’ve avoided the massive Ruby codebase.

In Summary

Fastlane is still essential in many iOS workflows, but its Swift interface feels like an afterthought.

I’m not calling for a full rewrite. Just the core features: building, testing, signing, and maybe a few more. The 20 percent that delivers 80 percent of the value.

That alone could make a huge difference.

I believe it’s worth it.