IN THE WORKS The developer guide. A preview of the proposed workflow.
buildlane.Explore Buildlane ↗

DEVELOPER GUIDE / QUICKSTART

Your code.
A clear path to release.

The proposed workflow for moving a mobile project from repository to signed, distributable build.

Buildlane is a product concept. These guides describe the intended experience; the configuration below is illustrative, and no live build service is connected.

01 / Connect a project

The planned onboarding flow starts with a GitHub or GitLab repository. Select the repository, default branch, and framework. Give the service access only to the repositories needed for your builds.

A good first build starts with a project that already builds locally. Commit its dependency lockfiles and record the toolchain versions your team uses.

02 / Define your workflow

Choose a runner and specify dependency installation, test, and build steps. The iOS toolchain requires macOS and Xcode; Android builds can use Linux with the Android SDK. Pin versions so a future release can reproduce your environment.

A workflow you can read

This example illustrates a possible Flutter workflow file. The final configuration format and supported keys have not been implemented.

# Illustrative configuration — not an executable Buildlane API
name: mobile-release
trigger:
  branch: main

jobs:
  ios:
    runner: macos
    toolchain:
      xcode: project-pinned-version
      flutter: project-pinned-version
    steps:
      - flutter pub get
      - flutter test
      - flutter build ipa --release
    artifacts:
      - build/ios/ipa/*.ipa
    distribution:
      destination: testflight
      approval: required

Reference secrets through the build environment. Keep signing certificates, provisioning profiles, and store credentials out of the repository and build logs.

03 / Choose your release lane

Native iOS

Use a macOS runner with the Xcode version required by your project. Select the workspace and scheme, run the tests, create an archive, and export the IPA with the appropriate signing configuration.

For TestFlight, you’ll need an Apple Developer account, a matching App Store Connect app record, and the relevant distribution credentials. Uploading starts Apple’s processing step; it does not guarantee store approval.

Native Android

Use the project’s Gradle wrapper and a compatible JDK and Android SDK. Run your test tasks before creating a release bundle with ./gradlew bundleRelease, adjusted for your module and build variant.

Store the upload keystore and passwords as secrets. Verify the application ID and version code, then distribute through a Google Play testing track before promotion.

Flutter

Pin Flutter, restore packages with flutter pub get, and run flutter test. Build iOS on macOS and Android on a Linux or macOS runner. Each platform still needs its own signing and store configuration.

Keep platform builds as separate jobs so failures and artifacts are easy to inspect.

React Native

Install dependencies using your project’s lockfile and pinned Node version. For iOS, restore CocoaPods dependencies and build the native Xcode workspace. For Android, use the native Gradle project.

The exact steps depend on your React Native version and whether your project uses Expo tooling. Keep native configuration and framework versions consistent across local development and CI.

04 / Inspect, then distribute

  1. Review the build logs and test results.
  2. Check the bundle or application ID, version, and signing identity.
  3. Download and test the resulting artifact.
  4. Send the same build to TestFlight or a Google Play testing track.
  5. Approve production distribution after testing and release review.

Buildlane’s proposed release model separates artifact creation from distribution. Your team decides when a build moves forward.

Try the homepage sample ↗