In fastlane, which upload_to_app_store and upload_to_play_store options release a llama-trekking booking app on iOS and Android with nobody at a console?

seniorshould knowfreq 54%

answer

every prompt is a CI hang
uploading is not submitting
force skips the confirmation prompt
submit_for_review, track, rollout
rehearse with verify_only and validate_only

basics

~20 s

On Apple's side upload_to_app_store needs submit_for_review, force to skip the confirmation prompt, and the submission and review information options; automatic_release, auto_release_date and phased_release control the release itself. On Google's side upload_to_play_store needs track, release_status and rollout.

solid answer

~40 s

Treat every interactive step as a defect. On Apple's side, upload_to_app_store uploads but does nothing further unless submit_for_review is set; force skips the metadata confirmation that otherwise hangs the job; run_precheck_before_submit and precheck_default_rule_level decide how strictly the listing is checked first; submission_information and app_review_information answer the declarations a person would otherwise type; and automatic_release, auto_release_date and phased_release decide when and how fast it goes out. On Google's side, upload_to_play_store needs track, release_status and rollout for a staged fraction, with changes_not_sent_for_review when the upload should not go to review yet. Rehearse with the dry runs — verify_only on Apple's action, validate_only on Google's — before the first unattended release night.

Treat every interactive step as a defect. On Apple's side, `upload_to_app_store` uploads but does nothing further unless `submit_for_review` is set; `force` skips the metadata confirmation that otherwise hangs the job; `run_precheck_before_submit` and `precheck_default_rule_level` decide how strictly the listing is checked first; `submission_information` and `app_review_information` answer the declarations a person would otherwise type; and `automatic_release`, `auto_release_date` and `phased_release` decide when and how fast it goes out. On Google's side, `upload_to_play_store` needs `track`, `release_status` and `rollout` for a staged fraction, with `changes_not_sent_for_review` when the upload should not go to review yet. Rehearse with the dry runs — `verify_only` on Apple's action, `validate_only` on Google's — before the first unattended release night.

code

ruby · 13 lines

ruby

lane :ios_public_release do
  upload_to_app_store(
    app_identifier: 'com.llamatrek.booking',
    api_key_path: ENV['ASC_API_KEY_PATH'],
    ipa: './build/LlamaTrek.ipa',
    skip_screenshots: true,
    force: true,
    run_precheck_before_submit: true,
    submit_for_review: true,
    automatic_release: true,
    phased_release: true
  )
end

go deeper

for a junior

Remember that the upload action does not submit anything by itself on Apple's side, and that a lane which stops to ask a question will simply hang on a build agent.

for a middle

Explain which option answers which interactive step: force for the confirmation, submit_for_review for the submission, track and release_status for what the Google Play upload becomes.

for a senior

Demonstrate the operating discipline: rehearse with verify_only and validate_only, start with a small rollout fraction, bound the call with timeout, and keep the upload retryable without a rebuild.

for a principal

Own where release decisions live. Deciding which choices are encoded in a Fastfile, which stay with a person, and who may trigger a public release is a governance question, not a scripting one.

In CI, a prompt is a failure

A release lane that works on a laptop can hang forever on a build agent, because the operator who answered the questions is gone. The design goal for the llama-trekking booking app's release lane is therefore blunt: every decision a human would make interactively has to become an option in the Fastfile, or the job stalls until someone kills it. The two stores hand you two different lists of such decisions, and there is no common set.

Apple's side: making upload_to_app_store finish on its own

upload_to_app_store (deliver) uploads and then stops unless you tell it otherwise. The options that carry a release the rest of the way:

submit_for_review — without it the action uploads the binary and metadata and leaves the version sitting there. This is the single most common surprise.
force — skips the confirmation on the generated metadata preview. Leave it out and the lane waits at a prompt no build agent will ever answer.
run_precheck_before_submit and precheck_default_rule_level — run the listing checks before submitting, and decide whether a finding stops the lane or only warns.
submission_information and app_review_information — the declarations and reviewer contact details a person would otherwise type into the form.
automatic_release and auto_release_date — release as soon as it is approved, or on a chosen date, instead of waiting for someone to press a button.
phased_release — hand the approved update out gradually rather than to everyone at once.
api_key_path — the machine credential, so no interactive sign-in appears anywhere in the chain.
skip_screenshots and skip_metadata — narrow what is uploaded when the release only needs the binary, which also shortens the window in which the lane can fail.

Google's side: making upload_to_play_store finish on its own

upload_to_play_store (supply) has no confirmation prompt to skip; its unattended-release problem is instead what the upload becomes once it lands:

track — which Google Play track receives the release.
release_status — whether the upload becomes an active release or is held rather than published.
rollout — a staged fraction of the audience rather than everyone. Raising it later is another call to the same action with a higher fraction and the artifact uploads skipped.
changes_not_sent_for_review — land the changes without sending them to review, with rescue_changes_not_sent_for_review as its companion for the case where the call is refused for that reason.
track_promote_to, track_promote_release_status and deactivate_on_promote — move an existing release onward without building anything new.
json_key_data — the machine credential, straight from a secret.
timeout — bound how long the call may wait, so a stuck upload fails the job instead of holding a runner.

What a human would click, and the option that answers it

The interactive step	iOS — `upload_to_app_store`	Android — `upload_to_play_store`
Confirm the metadata preview	`force`	no such prompt
Send it to review	`submit_for_review`	`changes_not_sent_for_review`, to not send
Answer the submission declarations	`submission_information`, `app_review_information`	not part of this action
Decide when it goes live	`automatic_release`, `auto_release_date`	`release_status`
Hand it out gradually	`phased_release`	`rollout`
Choose the audience	not part of this action	`track`
Rehearse without publishing	`verify_only`	`validate_only`

The table is the point of the question: the two lanes are not symmetric, and an engineer who has actually shipped both can say which store asks which question.

Rehearse before the first unattended night

Run the Apple lane with verify_only so the metadata and binary are checked and nothing is submitted.
Run the Google lane with validate_only so the upload is exercised without committing a release.
Aim the first real run at a low-risk target — a small rollout fraction, or a release_status that does not publish — so the first fully automatic execution is not also the first execution.
Assert the credentials before the upload starts, so a bad key fails in seconds rather than after a long transfer.
Keep build and upload in separate actions, so a rejected upload is retried without another build and re-sign.

What still needs a human

Setting these options removes the operator from the lane, not from the release. Review outcomes, the content of the declarations, and the judgment call to widen or stop a gradual rollout are decisions people still own — the lane only makes them expressible ahead of time. The mark of a senior answer here is naming both halves: the exact options that stop the job hanging, and the honest admission of what no option can automate.

## In CI, a prompt is a failure A release lane that works on a laptop can hang forever on a build agent, because the operator who answered the questions is gone. The design goal for the llama-trekking booking app's release lane is therefore blunt: **every decision a human would make interactively has to become an option in the Fastfile**, or the job stalls until someone kills it. The two stores hand you two different lists of such decisions, and there is no common set. ## Apple's side: making upload_to_app_store finish on its own `upload_to_app_store` (`deliver`) uploads and then stops unless you tell it otherwise. The options that carry a release the rest of the way: - `submit_for_review` — without it the action uploads the binary and metadata and leaves the version sitting there. This is the single most common surprise. - `force` — skips the confirmation on the generated metadata preview. Leave it out and the lane waits at a prompt no build agent will ever answer. - `run_precheck_before_submit` and `precheck_default_rule_level` — run the listing checks before submitting, and decide whether a finding stops the lane or only warns. - `submission_information` and `app_review_information` — the declarations and reviewer contact details a person would otherwise type into the form. - `automatic_release` and `auto_release_date` — release as soon as it is approved, or on a chosen date, instead of waiting for someone to press a button. - `phased_release` — hand the approved update out gradually rather than to everyone at once. - `api_key_path` — the machine credential, so no interactive sign-in appears anywhere in the chain. - `skip_screenshots` and `skip_metadata` — narrow what is uploaded when the release only needs the binary, which also shortens the window in which the lane can fail. ## Google's side: making upload_to_play_store finish on its own `upload_to_play_store` (`supply`) has no confirmation prompt to skip; its unattended-release problem is instead what the upload becomes once it lands: - `track` — which Google Play track receives the release. - `release_status` — whether the upload becomes an active release or is held rather than published. - `rollout` — a staged fraction of the audience rather than everyone. Raising it later is another call to the same action with a higher fraction and the artifact uploads skipped. - `changes_not_sent_for_review` — land the changes without sending them to review, with `rescue_changes_not_sent_for_review` as its companion for the case where the call is refused for that reason. - `track_promote_to`, `track_promote_release_status` and `deactivate_on_promote` — move an existing release onward without building anything new. - `json_key_data` — the machine credential, straight from a secret. - `timeout` — bound how long the call may wait, so a stuck upload fails the job instead of holding a runner. ## What a human would click, and the option that answers it | The interactive step | iOS — `upload_to_app_store` | Android — `upload_to_play_store` | |---|---|---| | Confirm the metadata preview | `force` | no such prompt | | Send it to review | `submit_for_review` | `changes_not_sent_for_review`, to not send | | Answer the submission declarations | `submission_information`, `app_review_information` | not part of this action | | Decide when it goes live | `automatic_release`, `auto_release_date` | `release_status` | | Hand it out gradually | `phased_release` | `rollout` | | Choose the audience | not part of this action | `track` | | Rehearse without publishing | `verify_only` | `validate_only` | The table is the point of the question: the two lanes are not symmetric, and an engineer who has actually shipped both can say which store asks which question. ## Rehearse before the first unattended night 1. Run the Apple lane with `verify_only` so the metadata and binary are checked and nothing is submitted. 2. Run the Google lane with `validate_only` so the upload is exercised without committing a release. 3. Aim the first real run at a low-risk target — a small `rollout` fraction, or a `release_status` that does not publish — so the first fully automatic execution is not also the first execution. 4. Assert the credentials before the upload starts, so a bad key fails in seconds rather than after a long transfer. 5. Keep build and upload in separate actions, so a rejected upload is retried without another build and re-sign. ## What still needs a human Setting these options removes the operator from the lane, not from the release. Review outcomes, the content of the declarations, and the judgment call to widen or stop a gradual rollout are decisions people still own — the lane only makes them expressible ahead of time. The mark of a senior answer here is naming both halves: the exact options that stop the job hanging, and the honest admission of what no option can automate.

The Android release went out at ten percent. How do you widen it from the same lane?
Call `upload_to_play_store` again with a higher `rollout` fraction and the artifact uploads skipped, so nothing new is published and only the fraction changes. Keep the same `package_name` and `track`, and name the `version_code` when no artifact is in the call, so the action edits the right release.
A release lane reports success but the iOS version never reached review. What is the likely cause?
`submit_for_review` was not set. `upload_to_app_store` uploads the binary and metadata and stops there by default, leaving the version editable in App Store Connect. The lane genuinely succeeded at what it was asked to do, which is why this is easy to miss until someone checks the version's state.

saying these in an interview costs you the question

Assuming an upload alone submits the release for review
Leaving the lane to answer the metadata confirmation prompt interactively
Thinking a hung CI job means a slow network
Believing phased_release exists on the Google Play upload action
Skipping a dry run because the lane worked last release
Putting a human login in the lane and retrying on failure

In fastlane, which upload_to_app_store and upload_to_play_store options release a llama-trekking booking app on iOS and Android with nobody at a console?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

In CI, a prompt is a failure

Apple's side: making upload_to_app_store finish on its own

Google's side: making upload_to_play_store finish on its own

What a human would click, and the option that answers it

Rehearse before the first unattended night

What still needs a human

▾common follow-ups2 questions

▾red flags6 flags

In CI, a prompt is a failure

Apple's side: making upload_to_app_store finish on its own

Google's side: making upload_to_play_store finish on its own

What a human would click, and the option that answers it

Rehearse before the first unattended night

What still needs a human

answer

go deeper