In fastlane, how do you choose between upload_to_testflight for iOS and the Firebase App Distribution plugin?

## Two channels that are not the same kind of thing The first thing to say is structural, not operational. **`upload_to_testflight` is a core fastlane action** — the canonical name behind the `pilot` and `testflight` aliases, shipping with fastlane itself. **Firebase App Distribution is a third-party plugin** (`fastlane-plugin-firebase_app_distribution`): its action does not exist until the plugin is declared in the project and installed on every machine and CI runner that runs the lane. That difference is not pedantry; it is a dependency you own, on a release cadence you do not control, in the middle of a pipeline whose greenness people trust. The second difference is reach. `upload_to_testflight` accepts an Apple binary — `ipa` or `pkg` — and nothing else. The plugin route is the one channel that can serve an Android artifact and an iOS one from the same shape of lane. ## What each one actually costs | | TestFlight via `upload_to_testflight` | Firebase App Distribution plugin | |---|---|---| | Origin | core fastlane action | third-party plugin, installed per project | | Platforms | Apple only (iOS, macOS, tvOS) | Android and iOS artifacts | | Latency to tester | Apple processes the build, and external distribution also goes through Apple's beta review | no Apple beta pipeline in the way | | iOS signing | store-signed build, installs on any tester's device | signed for install outside the store, so registered devices only | | Credential | App Store Connect API key (`api_key` / `api_key_path`) or Apple ID `username` | Google credentials, not an Apple key | | Fidelity | closest thing to the real install path | a side channel the shipped build never uses | ## Deciding, for the bookbinding order app The bookbinding order app is used by binderies to take and track custom binding orders, and it has two very different beta audiences: the four developers who want the build from the last merge, and the pilot binderies who install a release candidate and use it on the shop floor for a week. That split is the decision: 1. **If the audience is internal and the loop must be minutes**, use the plugin channel. Nothing about it waits on Apple, and the same lane shape works for the Android build the shop-floor tablets run. 2. **If the build is a release candidate**, use `upload_to_testflight`. The value is fidelity: the binary, its signing and its install path are the ones real users will get, so a problem that only appears in a store-signed build appears here rather than in production. 3. **If you can only maintain one channel**, keep the core one. A pipeline whose only route to testers depends on a plugin has a single point of failure outside fastlane. 4. **If the app is Android-only**, the question does not arise in this form: there is no core Android beta action, so the plugin — or a non-production Play track through `upload_to_play_store` (`supply`), which is a store lane — is the route. ## The signing consequence people forget On Android the plugin route is genuinely easy: the artifact is the artifact. On iOS it is not. A build distributed outside the App Store must be signed for outside-the-store install, which limits it to devices whose identifiers are in the profile the build was exported against. So the plugin channel is *one channel for two platforms* on the distribution side and **not** on the signing side. Teams that discover this late end up maintaining a device registry for the iOS half of a channel they adopted precisely to avoid maintenance. ## Wiring the choice into a script In practice a repository ends up with one beta lane per channel rather than a single lane with a flag buried inside it, because the two need different credentials, different artifacts and different failure messages. A driver — a CI job, or a parameter the invoking job passes — chooses which lane runs. Two rules keep it honest: - **Never let the two channels report the same success.** A green plugin upload does not mean an Apple-processed build exists. - **Never share a credential path between them.** Apple wants an App Store Connect API key; Google wants its own credential; a lane that reads one and expects the other fails late and confusingly. ## What an interviewer is listening for The weak answer is *TestFlight is official, Firebase is faster*. The strong answer names the structural asymmetry — core action against installed plugin, Apple-only against both platforms — states that Apple's processing and beta review are what the latency actually is, and then declines to pick one channel for all audiences, because the real production answer is two channels with two different meanings.