Fastlane
Fastlane CI on GitHub Actions
Fastlane lanes spend most of their time on bundle install and signing setup.
3m → 25s
Lane setup
31m → 12m
Full release
Fastlane lanes spend most of their time on bundle install and signing setup.
Why it happens
The Ruby gem cache and the signing keychain are recreated on every run.
What to change
- Cache vendor/bundle for the Fastlane gems
- Use match with a read-only role in CI so certificates are fetched, not regenerated
- Split build and upload into separate lanes so a failed upload does not rebuild
Fastlane on runnerhut
yaml
jobs: release: runs-on: runnerhut-macos-15-m4 steps: - uses: actions/checkout@v4 - uses: ruby/setup-ruby@v1 with: { bundler-cache: true } - run: bundle exec fastlane betaThe only runnerhut-specific line is `runs-on: runnerhut-macos-15-m4`. Everything else is standard GitHub Actions — the same actions, the same secrets and the same permissions model you use today.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
React NativeEvery build recompiles native iOS and Android dependencies from source.iOSXcode builds from scratch and code signing is fragile in CI.AndroidGradle re-resolves dependencies and the emulator has no hardware acceleration.FlutterThe Flutter SDK and pub cache download on every run, for every platform.