Solution

Automate app store deployment instead of clicking releases through by hand

A mobile release is rarely just a build. Signing, metadata, cropped screenshots, translated changelogs, version numbers and submissions to two or three portals cost time on every update.

Apple App Store, Google Play Store and Microsoft Store from one project
Signing material and store credentials managed centrally
macOS machines in the cloud for iOS builds, no box under a desk

Start for free. No credit card required.

In short

The platform automates everything that sits between finished code and a submitted release.

One project, three stores: the Apple App Store, Google Play Store and Microsoft Store from one project.
Signing is handled: keystores, Apple credentials and Azure artifact signing live in the platform.

Shipping store releases by hand versus through the platform

This shows which steps a manually assembled mobile release puts on your team and how much of that the Application Platform covers.

Task	With the Application Platform	Set up manually
Producing iOS and Android builds	Fully covered: The pipeline builds Flutter, Expo and native projects by the same rules	Not offered: Local builds on whichever machine is free, results hard to reproduce
A macOS environment for iOS	Fully covered: macOS machines in the cloud are part of the build infrastructure	Partly covered: Your own Mac or a rented runner, including Xcode upkeep
Managing signing material	Fully covered: Android keystores, Apple credentials and Azure artifact signing are stored in the platform	Not offered: Certificates and keystores sit with individuals, and losing one is a real risk
Maintaining store metadata	Fully covered: An editor with section navigation and language and platform badges inside the project	Not offered: The same copy maintained twice or three times across portals
Preparing screenshots	Fully covered: Screenshots are uploaded and cropped to the required formats in the editor	Not offered: Cropping in an image editor after looking up formats per store and device
Per-language changelogs	Fully covered: Release notes kept per language inside the project and versioned with it	Not offered: Copy and paste into store forms, with versions drifting apart
Google data safety declarations	Fully covered: The data safety details are part of the metadata editor	Not offered: Filled in by hand in the Play Console
Versioning and build numbers	Fully covered: Versioning happens in the pipeline and follows the state of the repository	Not offered: Counted up manually, with uploads rejected for duplicate build numbers
Submission and review status	Fully covered: Releases are triggered from the platform, with status visible per repository	Partly covered: Separate portals, different states, tracking kept in a side note
Serving the Microsoft Store too	Fully covered: Available as a third store from the same project	Not offered: A separate process, usually manual and rarely written down

Green means fully covered, amber partly, grey not offered. Store review times themselves do not change; everything before them does.

As of 10 August 2026. This comparison describes typical workflows and can differ from project to project.

What you get out of it

Less manual work exactly where releases usually stall.

Releases through Fastlane

Upload, signing and store communication run on Fastlane, wired into your project’s pipeline.

Signing in one place

Android keystores, Apple credentials and Azure artifact signing are managed centrally instead of living on developer machines.

Metadata editor

Section navigation, language and platform badges, screenshot cropping and per-language changelogs in a single interface.

macOS in the cloud

The GitLab CI configuration is readable inside your project and can be adapted to your own release rules.

Pipeline for Customer App

test

build

publish

release

The store release is the final step of the same pipeline.

How an app reaches the stores

Four steps from project creation to submission.

Create a mobile project

Pick Flutter, Expo or a native iOS or Android project. Repository, structure and pipeline are created alongside it.
Add store access

Apple credentials, Play Store access, the Android keystore and, if needed, Azure artifact signing are stored in the platform.
Fill in the listing

Titles, descriptions, keywords, screenshots, per-language changelogs and the Google data safety details are maintained in the editor.
Trigger the release

The pipeline builds, signs and uploads. You track the state per repository, and the store takes over for the review.

Frequently asked questions

Which stores are supported?

The Apple App Store, Google Play Store and Microsoft Store, all three from the same project. Metadata is maintained in one place, with badges for language and platform. The review itself still sits with each provider.

Do I need my own Mac for iOS builds?

No. The platform provides macOS machines in the cloud that run iOS builds and signing, which removes the box that otherwise sits in the office and needs maintenance with every Xcode update. You can also use those machines as a remote workspace.

How are certificates and keystores stored?

No, review times at Apple, Google and Microsoft stay what they are. Everything before that is automated: build, signing, metadata, screenshots, changelogs and upload. That shortens the gap to submission and cuts rejections from inconsistent details.

Ship your next release without the manual work