How to update App Store metadata without fastlane deliver in 2026

Version française →

fastlane deliver is the classic way to push App Store metadata from a repository: text files per language, screenshots in folders, one command. It works. It also brings Ruby, a folder tree to keep in sync with App Store Connect, and lanes to fix when Apple changes something.

Here is what deliver actually does, what is underneath it, and the other ways to get the same result.

What deliver does

From fastlane's own documentation: deliver uploads screenshots, App Preview videos, metadata and binaries to App Store Connect, and can submit the app for review.

fastlane deliver init                  # pull the current listing into ./fastlane/metadata
fastlane deliver download_screenshots  # pull the current screenshots
fastlane deliver                       # push metadata, screenshots, previews

Each language gets a folder with one file per field: name.txt, subtitle.txt, description.txt, keywords.txt, release_notes.txt, promotional_text.txt, support_url.txt, marketing_url.txt, privacy_url.txt. A default folder fills languages you don't override.

Options you will meet: skip_binary_upload, skip_screenshots, skip_metadata, overwrite_screenshots (off by default, so new screenshots are added rather than replacing), submit_for_review, automatic_release and phased_release. deliver also runs precheck before submitting.

The limits deliver has to respect

The third column is the part that bites people who write their own scripts: Apple splits a listing across two resources. Name, subtitle and privacy policy URL live on the app info, independent of any version. Description, keywords, What's New, promotional text and the support and marketing URLs live on the App Store version. Read only one of the two and half your fields come back empty.

Traps behind the API (from shipping it)

These come from building the same upload path in OneStore, not from the docs:

• Screenshots with an alpha channel are rejected after the fact. The commit request returns 200, then Apple's processing marks the screenshot as FAILED with IMAGE_ALPHA_NOT_ALLOWED, even when every pixel is opaque. Flatten PNGs before upload and check assetDeliveryState afterwards.
• What's New is required on every version localization of an update. A language created only for screenshots or the description, with an empty What's New, blocks the submission.
• The version must exist and be editable. You can't edit metadata on a version that is waiting for review or live. You need a version in an editable state (prepare for submission, rejected, metadata rejected).
• Name and subtitle can't change on a live version without a new version. They sit on the app info that goes with the version you are preparing.

Four other ways to push the listing

1. App Store Connect, by hand

Fine for one app in one or two languages. It becomes copy-paste work as soon as you have five languages, and nothing checks the Google Play version of the same text.

2. The App Store Connect API directly

What deliver uses under the hood: an API key (.p8), a signed JWT, then PATCH calls on appInfoLocalizations and appStoreVersionLocalizations, and the screenshot reservation flow (reserve, upload the bytes, commit, poll the delivery state). Full control, and all the traps above are yours.

3. EAS Metadata

If you use Expo, eas metadata:push sends the App Store listing from store.config.json. Expo marks it as beta; it doesn't support Google Play and can't upload screenshots.

4. A tool with an interface

OneStore edits the App Store and Google Play listings in one form, every language, with each store's limits checked as you type, then pushes both. It writes each field to the right Apple resource, flattens screenshot transparency before upload, resizes one HD screenshot into every required size, and checks the version before you submit (build, screenshots, export compliance, age rating, What's New in every language). No Ruby, no metadata folder.

When to keep deliver

If your listing already lives in Git, your releases are fully scripted in CI and someone on the team maintains the Fastfile, deliver remains a good tool. If the listing is edited by people who don't open a terminal, or you also ship on Google Play and want both stores side by side, a shared interface saves the round trips.

Related: fastlane vs EAS Submit, App Store Connect upload errors and how to fix them, App Store Connect vs Google Play metadata.

FAQs