Publishing your app store listing without fastlane

fastlane is the default answer for a reason. It is a free, MIT-licensed toolkit, and its deliver action (aliased upload_to_app_store) uploads screenshots, app preview videos, metadata, and the binary to App Store Connect in a single command. On the Android side, supply (aliased upload_to_play_store) does the same for Google Play — metadata, screenshots, and the APK or app bundle. Run either from CI and your listing regenerates on every release, never drifting from the app.

So the honest question is not "is fastlane good" — it is. The question is whether you want to own the pipeline that makes it good, or whether you would rather update a listing without one.

What deliver and supply actually do

Both are wrappers around the official store APIs. Behind the scenes, fastlane is making the same calls you could make yourself.

• deliver (iOS). Uploads app name, description, keywords, release notes, URLs, categories, and review information, plus localized screenshots and preview videos. The binary goes up via Apple's iTMSTransporter; the metadata goes through the App Store Connect API. It can also submit for review after upload.
• supply (Android). Uploads metadata, screenshots, and the APK or AAB to Google Play, choosing a track and promoting builds. Note the sharp edge: uploaded screenshots replace the existing ones for a locale rather than adding to them.

Both authenticate with API keys — an App Store Connect API key for Apple, a service-account JSON for Google — so once configured they run unattended in CI. That is the whole appeal: metadata and screenshots as code, versioned in your repo, shipped on every build.

The real cost of fastlane

fastlane is free to install and free to run. The cost is the setup and the upkeep, and it is paid in engineering time.

• A runtime to maintain. fastlane is a Ruby toolchain (Ruby 3.0+), usually managed with Bundler. iOS work needs Xcode on a Mac; Android needs the Gradle side. That is real machinery to install and keep patched.
• Config files to write. A Fastfile defines your lanes; a Deliverfile or the Android metadata folder holds the listing details. Getting the first working version right is typically a day or two.
• CI to stand up. The automation only pays off inside a pipeline, which means API keys, signing secrets, and a build runner configured and kept green.
• Screenshot capture upkeep, if you use it. fastlane's snapshot drives UI tests in the simulator to capture screenshots per locale. Those tests are brittle: a common report is that a setup runs well for a couple of months, then a UI change breaks the flow and the test code has to be re-navigated to the new states. snapshot retries flaky runs by default, which papers over network- and data-driven non-determinism rather than fixing it. And the raw output has no captions or backgrounds — teams often finish the design in a separate tool anyway.

None of this is a knock on the tool. It is the honest trade: fastlane converts a recurring manual chore into code, and in return you maintain code. For a team shipping weekly with an engineer who owns release automation, that is a good deal. For a solo maker or a PM who updates a listing a few times a year, the pipeline can cost more to keep alive than it saves.

Updating a listing without fastlane

If you skip fastlane, you still have three ways to get metadata and screenshots onto the stores.

1. The store web consoles

The plainest path. In App Store Connect you edit each localization by hand and drop screenshots into the display-size slots; in Google Play Console you edit the store listing per language and upload screenshots there. No code, no keys, nothing to maintain — you point and click. The downside is that it is entirely manual, and doing it across many locales one screen at a time is slow and error-prone. Fine for one or two languages; painful at 20.

2. The store APIs, directly

Both stores expose the same APIs fastlane calls, so you can script against them without adopting fastlane's Ruby stack. Apple's App Store Connect API is a REST API authenticated with a short-lived JWT (ES256, signed with your key), with endpoints to create screenshot sets, reserve and upload image bytes, and patch metadata. Google's Play Developer API uses an "edits" model — you open an edit, change listings and images, then commit it. This gives you full control and fits a custom internal dashboard, but you are now writing and maintaining that integration yourself. It is a smaller commitment than a full fastlane pipeline, not a zero one.

3. A managed tool that drafts the listing

The other no-code route is a tool that produces the listing for you, so the only thing left is to get it onto the store. This is where the trade-off inverts: instead of an engineer owning a pipeline, a PM or designer owns the listing directly in a browser. You are trading CI automation for not needing an engineer at all.

Where Mokbi fits — honestly

Mokbi does not try to replace fastlane's CI story. If your goal is screenshots that regenerate from every build with no human in the loop, a fastlane pipeline is the right tool and it is free. We are for the other case: the person who wants to ship a polished listing without touching Ruby, Xcode, a Fastfile, or a UI test.

In the browser you design the screenshots, draft the store text, and translate the whole listing into 50 languages — no simulator, no CI, no code. A designer or PM can own the entire marketing surface end to end.

Here is the last mile, and Mokbi covers it. It designs the screenshots and the feature graphic, writes and translates the whole listing into 50 languages, then pushes the result straight to Google Play through the Play Developer API and stages the App Store version in App Store Connect, ready for you to hit Submit — Apple requires that final Submit and its review itself, an Apple rule, not a gap on our end. Same endpoints fastlane calls, minus the pipeline.

When to pick which

• Ship weekly, have an engineer, want zero drift? fastlane. It is free, it is automated, and it keeps screenshots and metadata in lockstep with the app. Nothing here beats that.
• Update a listing a few times a year, no CI to spare? The web console, or a tool that drafts the listing. The pipeline's upkeep is not worth it at that cadence.
• Need programmatic control but not fastlane's stack? Call the App Store Connect and Play Developer APIs directly.
• Want a designer or PM to own the listing across many languages? Draft, translate, and publish from the browser — Mokbi pushes to Google Play and stages the App Store version ready for you to submit.

fastlane earns its place as the free, automated incumbent. The no-code path is not "better" — it is a different trade: you give up the CI automation, and in exchange nobody has to build or babysit a pipeline to update a listing.

What to read next

• The best app store listing publishing tools
• Uploading screenshots with the App Store Connect API
• Side-by-side: Mokbi vs fastlane

Open the editor →