What does fastlane's build_app action (gym) produce for an iOS app?

## What `build_app` actually is `build_app` is a built-in **fastlane action** — one of the steps you call from a lane in a `Fastfile`. Its famous short name `gym` is an **alias**: both spellings run the same code, and `build_app` is the canonical name to use in new lanes and to say out loud in an interview. Its single job is to drive Apple's `xcodebuild` command-line tool so that a checkout of an iOS project becomes a signed, distributable package with nobody opening Xcode. It is **Apple-only**. There is no Android path through `build_app`; an Android artifact comes out of the Android build system, which is a different tool and a different lane. Talking about "the build lane" without naming the platform is the fastest way to sound like you have only skimmed the README. ## The inputs it cannot guess `build_app` carries dozens of options, but a handful actually decide the outcome: - `scheme` — the Xcode **scheme** to build. A scheme says which targets compile, which configuration each action uses, and which target is archived. A project holding an app, a widget extension and a UI-test target gives `build_app` nothing safe to guess from, so name it. - `workspace` or `project` — which Xcode container to open. Use `workspace` when a dependency manager generated one, `project` for a bare `.xcodeproj`. - `configuration` — the Xcode build configuration. `Release` for anything you distribute; `Debug` only for a local smoke build. - `export_method` — which Apple distribution channel the exported package is signed for. - `output_directory` and `output_name` — where the package lands and what it is called. Everything else — `clean`, `sdk`, `destination`, `include_symbols`, `xcargs` — refines a build that already works. ## Two Xcode phases, not one `build_app` invokes Apple's toolchain twice, and knowing that seam is what separates a junior answer from a middle one. 1. **Archive.** It runs Xcode's archive action for your `scheme` and `configuration`, producing an `.xcarchive` bundle at `archive_path`. The archive holds the built iOS app **and** its debug-symbol (`dSYM`) bundles — the files that later turn a stack of hexadecimal addresses in a crash report back into function names and line numbers. 2. **Export.** It then runs Xcode's export step over that archive with an export-options property list, signing and repackaging the app for exactly one destination. This is where `export_method` and `export_options` apply. You can stop after either phase. `skip_archive` and `skip_build_archive` skip ahead when an archive already exists; `skip_package_ipa` archives without exporting, which is what a compile-only pull-request check on our lighthouse maintenance app wants; `skip_codesigning` archives an unsigned iOS app for the same reason. ## What lands on disk | Artifact | Controlled by | Consumed by | |---|---|---| | Signed `.ipa` | `output_directory`, `output_name` | `upload_to_testflight` (`pilot`), `upload_to_app_store` (`deliver`) | | `.xcarchive` | `archive_path` | a later re-export, and symbol recovery | | dSYM bundles | carried in the archive; `include_symbols` for the export | your crash reporter | | Raw `xcodebuild` log | `buildlog_path` | you, when it fails | | `.xcresult` bundle | `result_bundle`, `result_bundle_path` | build report viewers | For a macOS target the packaged artifact is a `.pkg` rather than an `.ipa`, and `skip_package_pkg` is its skip switch. ## How the next action finds the binary `build_app` returns the path of the package it built and also publishes it into fastlane's shared lane context: `Actions.lane_context[SharedValues::IPA_OUTPUT_PATH]` holds the `.ipa` path and `SharedValues::PKG_OUTPUT_PATH` the macOS `.pkg` path. That is why a lane can call `build_app` and then `upload_to_testflight` with no filename written between them — the second action reads the first action's output out of the context. It is also why hardcoding a path is a smell: change `output_name` and the hardcoded string rots, while the context value does not. ## What `build_app` is deliberately not - It does **not** create or fetch signing assets. Apple certificates and provisioning profiles come from `sync_code_signing` (`match`); `build_app` only consumes what is already on the machine. - It does **not** upload anything. Shipping the binary is `upload_to_testflight` (`pilot`) for Apple's beta service and `upload_to_app_store` (`deliver`) for the store listing. - It does **not** build for Google Play. Nothing inside `build_app` touches an Android artifact. Keeping those three seams straight is most of what an interviewer is checking. The candidate who answers "gym builds and ships it" has merged three lanes into one, and will not know where to look on the day only the upload fails.