Fastlane for React Native in 2026: When You Still Need It

Fastlane was, for years, the answer to "how do we stop building and uploading mobile apps by hand?" Then Expo's EAS services arrived and handled builds, signing and submission without a single Ruby file, and many teams quietly deleted their Fastfile.

So is Fastlane still worth using for React Native in 2026? For many Expo projects, no, because Expo's own services now cover signing, cloud builds and store submission end to end. For bare projects with their own build machines, custom native steps or strict infrastructure rules, it's still one of the best tools available. This guide explains what Fastlane does, where EAS replaces it, where it still wins, and gives you a working Fastfile.

Key takeaways

• Fastlane automates the native release steps: signing, building, uploading to TestFlight and Google Play, metadata and screenshots.
• For Expo projects, EAS Build and EAS Submit cover most of what Fastlane did, with less setup.
• Fastlane still fits bare projects, self-hosted macOS runners, teams that keep store metadata in the repo, and organisations that can't use cloud builds.
• match remains a good way to share iOS signing across a team and CI, using an encrypted Git repo or cloud storage.
• You can combine them: EAS for builds, Fastlane for metadata or screenshots.

What Fastlane does

Fastlane is an open-source tool that runs "lanes": scripted sequences of actions for iOS and Android releases. The actions React Native teams use most:

A working Fastfile for a bare React Native app

# fastlane/Fastfile
default_platform(:ios)

platform :ios do
  desc "Build and upload to TestFlight"
  lane :beta do
    setup_ci if ENV["CI"]
    app_store_connect_api_key(
      key_id: ENV["ASC_KEY_ID"],
      issuer_id: ENV["ASC_ISSUER_ID"],
      key_content: ENV["ASC_KEY_CONTENT"]
    )
    match(type: "appstore", readonly: true)
    increment_build_number(xcodeproj: "ios/YourApp.xcodeproj")
    build_app(workspace: "ios/YourApp.xcworkspace", scheme: "YourApp")
    upload_to_testflight(skip_waiting_for_build_processing: true)
  end
end

platform :android do
  desc "Build and upload to Play internal testing"
  lane :beta do
    gradle(task: "bundle", build_type: "Release", project_dir: "android/")
    upload_to_play_store(
      track: "internal",
      aab: "android/app/build/outputs/bundle/release/app-release.aab"
    )
  end
end

Run fastlane ios beta or fastlane android beta locally or in CI. Store the App Store Connect API key, the match password and the Google Play service account key as CI secrets.

Submitting for review with Fastlane

upload_to_app_store (Fastlane's deliver action) uploads metadata, screenshots and the build, and can submit the version for review in the same lane:

upload_to_app_store(
  ipa: "./build/App.ipa",
  submit_for_review: true,
  automatic_release: false, # release manually once approved
  force: true                # skip the HTML preview in CI
)

For Google Play, upload_to_play_store does the same, with track: "internal" for testers or a staged rollout fraction for production. In an Expo project, run npx expo prebuild to generate the native folders first, or let EAS Submit handle store uploads instead.

When EAS replaces Fastlane

If you use Expo with Continuous Native Generation, EAS is usually the simpler path. If you maintain the native projects by hand, Fastlane fits naturally.

When you still need Fastlane

• Bare projects with custom native build steps that are easier to script directly.
• Self-hosted macOS runners, for cost, speed or security reasons.
• "Code never leaves our infrastructure" policies that rule out cloud builds.
• Store metadata as code: descriptions, release notes and screenshots versioned in Git and uploaded on release.
• Automated, localised screenshots across many devices and languages.

From the field: Fastlane with GitHub Actions sits in my release toolkit next to EAS Build, Submit and Update. On Expo projects I lean on EAS; where a project's build has to run on its own machines, Fastlane is still the most dependable way to script iOS signing and uploads.

Moving from Fastlane to EAS (or the other way)

Teams switch in both directions, and neither move has to be all-or-nothing.

From Fastlane to EAS: start by building with EAS while keeping your existing signing. EAS can use credentials you provide, so you don't have to regenerate certificates on day one. Once builds are reliable, move submission to EAS Submit, then retire the Fastlane lanes you no longer run. If you rely on deliver or supply for metadata, keep those lanes; they work fine alongside EAS builds.

From EAS to Fastlane: this usually happens when a company moves builds onto its own infrastructure. Download your credentials from EAS first, set up match (or your own signing storage), and run Fastlane builds in parallel with EAS for a few releases before switching over.

On cost: EAS charges a monthly plan plus per-build prices beyond the included credit. Fastlane itself is free, but iOS builds need macOS machines, either your own or hosted CI runners, which are billed at higher rates than Linux runners, plus the time someone spends maintaining Xcode, Ruby and signing. For small teams, EAS usually works out cheaper once maintenance time is counted. For teams already running macOS build farms, Fastlane often wins.

Common Fastlane problems

• Two-factor prompts in CI: use an App Store Connect API key instead of an Apple ID password.
• Signing mismatches: run match in read-only mode in CI, and regenerate only from one trusted machine.
• Ruby and gem conflicts: pin Fastlane in a Gemfile and run it with bundle exec.
• Slow iOS builds: cache CocoaPods and derived data, and use larger runners for release builds.
• Expired certificates: iOS distribution certificates expire. Put the expiry date in your team calendar and renew from one machine with match, then let every other machine sync.

FAQ

Do I need Fastlane with Expo?

Usually not. EAS Build handles signing and building, and EAS Submit uploads to the stores, which covers what most Expo teams used Fastlane for. Fastlane is still useful alongside Expo for metadata management or automated screenshots.

Is Fastlane still maintained in 2026?

Fastlane remains a widely used open-source project for iOS and Android automation, and its core actions for signing, building and uploading are standard in many mobile CI pipelines. Check its documentation and release notes for the current state before adopting it.

What is fastlane match?

match is a Fastlane action that creates iOS signing certificates and provisioning profiles once and stores them encrypted in a Git repository or cloud storage. Every developer and CI machine then syncs the same credentials, which avoids the classic "it only signs on Sam's Mac" problem.

Can I use Fastlane and EAS together?

Yes. A common split is EAS for builds and over-the-air updates, and Fastlane's deliver and supply for uploading store metadata and screenshots from the repository. Keep one source of truth for signing to avoid conflicts.

Next steps

If you're deciding between Fastlane and EAS, or untangling a pipeline that only works on one machine, I can help you set up the simplest reliable option. Get in touch, or see my services.

Sources

• Fastlane documentation, Fastlane
• match, Fastlane
• App Store Connect API key in Fastlane, Fastlane
• EAS Build introduction, Expo
• EAS Submit, Expo